Silvio Knizek wrote:
the proper approach would be to define the dependency of the generated
.service to the mount point with a drop-in and RequiresMountsFor=. See
man:systemd.unit for more information.
How would that work for init.d scripts?
Also the systemd-sysv-generator can only do so much.
1) If the systemd-sysv-generator creates wrapper .service files on-the-fly,
is it possible to hook into those with dropins? The man page didn't
give much information.
2) If init.d scripts are wrapped by .service files, shouldn't the
processes spawned by these scripts be killed when shutting down?
For my example init.d script I see this with "sytemctl status bla":
CGroup: /system.slice/bla.service
└─9997 /usr/bin/sleep 99d
But after "systemctl stop bla", the sleep process is still there.
When I write a .service unit of type oneshot with RemainAfterExit=yes
that calls a script that spawns another sleep process, I see the same
structure:
CGroup: /system.slice/blu.service
└─24351 sleep 44d
But after "systemctl stop blu" this sleep is gone.
So why doesn't the .service wrapper for the init.d script
kill the processes it has spawned? Is that a bug?
That would likely solve most of the problems with init.d scripts
even for iscsi mounts due to the ordering that can be done with
$remote_fs.
Please write yourself proper units if you encounter problems.
I'm not writing init.d script, I always use units for my own
stuff. I'm talking about init.d scripts that are still delivered with
many software packages and that I wouldn't like or try to rewrite.
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
