[systemd-devel] systemd-sysv-generator bug ?

[Andrei Borzenkov]

On Tue, Nov 22, 2016 at 10:38 AM, Cédric BRINER <cedric.briner at unige.ch> wrote:
> Hi,
>
> We have been through a lot of tests, trying to make it reproductible
> with some easy scripts. You'll see at the bottom of this email, some
> links on the scripts used, what we have typed in our console, and the
> output of journalctl -b -1
>
>> systemd will only stop services at shutdown that are running. That
>> means you need to make sure your SysV script is properly hooked into
>> the start runlevels too, even if its start verb is just a nop.
> Mixing your comment, and the one from Reindl HARALD, we have a
> sysv-test.service which has /usr/bin/true for ExecStart, and a
> stop-sysv-test.bash for ExecStop which stops a daemon launched within
> the console.
>
> Before the init 6 we had:
> # systemctl status sysv-test
> ● sysv-test.service - sysv-test
>    Loaded: loaded (/etc/systemd/system/sysv-test.service; enabled;
> vendor preset: disabled)
>    Active: active (exited) since lun 2016-11-21 15:03:23 CET; 12min ago
>  Main PID: 2562 (code=exited, status=0/SUCCESS)
>    CGroup: /system.slice/sysv-test.service
>
> nov 21 15:03:23 beryl5 systemd[1]: Started sysv-test.
> nov 21 15:03:23 beryl5 systemd[1]: Starting sysv-test...
>
>
> Now, when you look at the journalctl, you'll see that before the
> ExecStop starts:
> * write-sysv-test.pl is killed.
> * the fs /oracle/BAS/oraarch a "local-fs" is already unmounted.
>

Script that you start manually runs as part of login session and is
stopped concurrently with your service. So the first problem is, it
will be probably killed by logind when session terminates (user
exits), at least this is what current systemd version does by default.

It is possible to use systemd-run to start process in different scope
(outside of current session), then you still need to enable lingering
for this user.

Assuming that your command survives normal session exit - does adding
"After=user.slice" to your service helps? This should ensure your
service is stopped before any user processes.

>
> The difficulty that we have, is how to have a daemon, no launched by
> systemd that can stop nicely by:
>  - having its filesystem during the stop of the daemon.
>  - able to use a stop script.
>

Mount units are also propagated to systemd user instance. So you
probably can also run this unit in systemd user context and have usual
dependencies on filesystems (like RequiresMountsFor) - at least, I
think so :) You will need to enable lingering then as mentioned
already. User instances are stopped on shutdown too.