[systemd-devel] failing unmounts during reboot

Frank Steiner fsteiner-mail1 at bio.ifi.lmu.de
Thu Jul 25 11:29:19 UTC 2019


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. *


More information about the systemd-devel mailing list