Bug#854197: systemd: please handle the case where socket activation leads to restart loop better

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Christian

On Sun, 5 Feb 2017 00:05:03 +0100 Christian Seiler <christian at iwakd.de>
wrote:
> while helping out on debian-mentors@ with #854192 I noticed that systemd
> doesn't appear to handle the case very well when dbus is installed but not
> configured properly (this was due to a bug in the usbguard package that
> missed a dependency on dbus), trying to start a Type=dbus service (that
> does DBus requests) will cause a nasty restart loop that you can only get
> out of if you stop dbus.socket - but it's very non-obvious that that is
> what you should do.
> 
> Steps to reproduce:
> 
>  - install a stretch system, minimal (tasksel empty), no DBus
>  - Recreate a broken DBus installation:
>       apt-get download libdbus-1-3 dbus
>       dpkg --install libdbus-1-3_*.deb
>       dpkg --unpack dbus_*.deb
>  - Create a dummy service:
>       cat > /etc/systemd/system/dummy.service
>       [Service]
>       BusName=org.example.dummy
>       ExecStart=/usr/bin/dbus-monitor --system
>       (Ctrl+D)
>  - Try to start that service
>       systemctl daemon-reload
>       systemctl start dummy
> 
> The dbus-monitor startup will cause dbus.socket to be triggered, which
> in turn will cause systemd to try to start dbus.service. Problem here is
> that dbus's postinst won't have run yet, so the "messagebus" user won't
> exist, so dbus-daemon won't start up propery.
> 
> Problem: this creates a restart loop, since systemd tries to restart
> the service over and over again because there's data on the DBus socket.
> I'm pretty sure you could also reproduce that with other services that
> are socket activated, but this definitely reproduces this.
> 

It seems I can't reproduce the problem with the steps you provided in
stretch VM. This is what I get:

> Sep 03 13:29:45 debian systemd[1]: Listening on D-Bus System Message Bus Socket.
> Sep 03 13:29:45 debian systemd[1]: Starting dummy.service...
> Sep 03 13:29:45 debian systemd[1]: Started D-Bus System Message Bus.
> Sep 03 13:29:45 debian dbus-daemon[856]: Failed to start message bus: Could not get UID and GID for username "messagebus"
> Sep 03 13:30:10 debian systemd[1]: Failed to subscribe to NameOwnerChanged signal for 'org.example.dummy': Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to subscribe to NameOwnerChanged signal for 'org.freedesktop.login1': Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to subscribe to activation signal: Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to register name: Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to set up API bus: Connection timed out
> Sep 03 13:30:10 debian systemd[1]: dbus.service: Main process exited, code=exited, status=1/FAILURE
> Sep 03 13:30:10 debian systemd[1]: dbus.service: Unit entered failed state.
> Sep 03 13:30:10 debian systemd[1]: dbus.service: Failed with result 'exit-code'.
> Sep 03 13:31:15 debian systemd[1]: dummy.service: Start operation timed out. Terminating.
> Sep 03 13:31:15 debian systemd[1]: Failed to start dummy.service.
> Sep 03 13:31:15 debian systemd[1]: dummy.service: Unit entered failed state.
> Sep 03 13:31:15 debian systemd[1]: dummy.service: Failed with result 'timeout'.

I.e. the usual 90s timeout kicks in, after which the systemctl start
attempt fails.

Can you please double check that this is really still an issue with
stretch (and ideally with buster as well).

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190903/46eb8604/attachment.sig>