[systemd-devel] systemd update "forgets" ordering for shutdown

[Michael Chapman]

On Sun, 17 May 2020, Andrei Borzenkov wrote:
> 17.05.2020 03:32, Michael Chapman пишет:
> > On Fri, 15 May 2020, Frank Steiner wrote:
> >> Hi,
> >>
> >> I need to run a script on shutdown before any other service is stopped.
> >> Due to an advice Lennart gave a while ago I'm using this service file
> >> (with multi-user.target being our default runlevel target):
> >>
> >> [Unit]
> >> After=multi-user.target
> >>
> >> [Service]
> >> Type=oneshot
> >> ExecStart=/bin/true
> >> ExecStop=/usr/lib/systemd/scripts/halt.local.bio
> >> TimeoutSec=120
> >> RemainAfterExit=yes
> > 
> > This seems inherently fragile.
> > 
> > If `multi-user.target` were to be stopped for whatever reason (and this 
> > is generally possible), the ordering dependencies between services 
> > Before=multi-user.target and services After=multi-user.target are broken. 
> 
> This is universally true. Do you have suggestion how it can be done
> differently?

Perhaps ordering dependencies should propagate through units even when 
they are not part of the transaction?

If we have A.service before B.service before C.service, we probably still 
want A.service before C.service even if B.service is not part of the 
transaction.

I must admit I haven't figured out the repercussions of this... but I'm 
pretty sure it's closer to how people *think* systemd's ordering 
dependencies work.

> Even if multi-user.target is manually stopped, there is no way normal
> service can be stopped concurrently with local filesystems, simply
> because normal service is always ordered After=basic.target. Unless of
> course we manually stop basic.target and sysinit.target as well :)

Well, that's actually my concern... there's really nothing preventing 
those targets from being "accidentally" stopped. That could happen at some 
point during the system's uptime, and utter chaos would ensue the next 
time the system was shutdown.
 
> I cannot reproduce it using trivial service definition on openSUSE Leap
> 15.1 which should have the same systemd as SLE 15 SP1. So possibilities are
> 
> 1. Something in unit definition triggers some bug in systemd. In this
> case exact full unit definition is needed. Also shutdown log with debug
> log level will certainly be useful.
> 
> 2. ExecStop command is not synchronous, it forks and continues in
> background. In this case probably systemd assumes unit is stopped and
> continues. Again, log with debug log level would confirm it.

I agree, we do need to find out exactly what happened with Frank's system. 
There's clearly something more to it if his service is surviving 
local-fs.target being stopped.