[systemd-devel] Generic problems with dependencies for on-demand services on shutdown

[Andrey Borzenkov]

Another obvious example is syslog.target. On startup we have

rsyslog.service -> syslog.target -> everything that requires syslog

but on shutdown rsyslog is stopped far too early to actually log
anything. And if I explicitly order NM after rsyslog.service it is
terminated before D-Bus (apparently) and does not crash. So either we
have crash that cannot be logged anywhere or we do not crash and
cannot log it anyway :)

On Sun, Feb 20, 2011 at 12:30 PM, Andrey Borzenkov <arvidjaar at gmail.com> wrote:
> networkmanager crashes on shutdown every time. There is a fix to avoid
> this crash, but it reveals some quite fundamental issue.
>
> On startup we have
>
> dbus.socket -> dbus.target -> services that are After dbus.target
>
> So far so good. dbus.service is implicitly pulled in by first connect
> to dbus.socket and everyone is happy
>
> But on *shutdown* we apparently do not have any sort of valid
> ordering. Which means dbus is snatched away unexpectedly at arbitrary
> time. While of course services must be able to cope with it, they may
> want to do some cleanup on clean shutdown, and we deprive them of
> this.
>
> Lennart, do you have clever idea how to express such dependency? This
> seems to be inherent issue for any type of socket activation. Somehow
> we *must* mark any service that requires foo.socket that spawns
> foo.service as ordered After foo.service (or Before on shutdown). We
> need some generic way to compute such dependency. Right now there is a
> gap between dbus.service and dbus.target, where the former is
> completely hidden from all consumers.
>
> Same issue with D-Bus activation BTW. Anything started by D-Bus must
> be ordered after D-Bus itself. This should happen dynamically. Ideally
> is service foo triggers service bar via D-Bus (or socket or whatever),
> service bar should be ordered After service foo. Do we have enough
> information to do it?
>