[Pkg-utopia-maintainers] Bug#940971: libnss-systemd: /etc/init.d/dbus blocks for 90 seconds when booting with sysvinit

[Simon McVittie]

Control: reassign -1 libnss-systemd 242-7
Control: retitle -1 libnss-systemd: /etc/init.d/dbus blocks for 90 seconds when booting with sysvinit
Control: affects -1 dbus

On Mon, 23 Sep 2019 at 13:01:11 +0200, Simon Richter wrote:
> On Sun, Sep 22, 2019 at 09:01:48PM +0100, Mark Hindley wrote:
> > > /etc/init.d/dbus is hanging pretty much exactly 90 seconds on either boot
> > > or manual start:
> 
> > I have observed similar behaviour on sysvinit systems which still have systemd
> > installed.
> 
> > I think it is related to libnss-systemd: removing it gets rid of the hang for
> > me.
> 
> So this is likely a bug in libnss-systemd.

Sounds like it.

Summary for the systemd maintainers: the steps to reproduce seem to be:

- install with systemd (and have libnss-systemd installed, as it is
  by default)
- have dbus installed
- replace systemd-sysv with sysvinit
- do not remove systemd
- do not remove libnss-systemd
- reboot, so sysvinit is now pid 1

Expected result: dbus starts promptly

Actual result: /etc/init.d/dbus blocks for 90 seconds, then starts
(successfully, I think? it isn't completely clear to me from the original
bug report)

If libnss-systemd is in the critical path for the equivalent of
`getent hosts messagebus`, and it times out / fails-over to the next NSS
module after 90 seconds, then that would be consistent with the observed
behaviour of /etc/init.d/dbus.

If that guess is correct, then this would affect any username resolution
(not just dbus), and would affect any non-systemd boot (for example
init=/bin/bash on an otherwise purely systemd system).

libnss-systemd should probably disable itself (behave as though it did
not know anything about any usernames) if it does not find evidence that
systemd is pid 1?

    smcv