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