If the dbus daemon (or the machine) dies unexpectedly it leaves an orphaned "pidfile" (in /var/run/messagebus.pid on RH based Linux). When one tries to restart the dbus-daemon it fails to start with: Failed to start message bus: The pid file "/var/run/messagebus.pid" exists, if the message bus is not running, remove this file And continues to do so until the file is removed by some external force. Is this by design? Is there some philosophical objection to having dbus-daemon detect that the file is orphaned and remove and then start?
(In reply to comment #0) > Is this by design? Is there some philosophical objection to having dbus-daemon > detect that the file is orphaned and remove and then start? Not particularly, but detecting that it's orphaned is the sort of platform-specific goo that platforms/distributions/init-scripts can usually do better (e.g. the sysvinit script shipped in Debian uses /lib/lsb/init-functions - which isn't necessarily universal, but can be depended on by the Debian package - for this check, while the systemd unit takes advantage of systemd's better state-tracking to be able to remove the pid file unconditionally). I wouldn't object to detection of an orphaned pid file if you can provide a good patch that looks suitably portable, but there might be some debate about what "orphaned" and "portable" mean.
I'm tempted to say that this is WONTFIX, and that init scripts or equivalent are responsible for doing whatever OS-specific stale pidfile cleanup is appropriate. Under systemd, we don't use a pidfile at all.
(In reply to comment #2) > I'm tempted to say that this is WONTFIX, and that init scripts or equivalent > are responsible for doing whatever OS-specific stale pidfile cleanup is > appropriate. > > Under systemd, we don't use a pidfile at all. Maybe what is unclear in all of this is what exactly is creating /var/run/messagebus.pid? Does dbus itself create that when it starts up or does it delegate that to whatever starts it (i.e. initscripts, systemd, etc)? I.e. if whatever starts it doesn't create one, it won't be there?
(In reply to comment #3) > Maybe what is unclear in all of this is what exactly is creating > /var/run/messagebus.pid? Does dbus itself create that when it starts up or > does it delegate that to whatever starts it (i.e. initscripts, systemd, > etc)? I.e. if whatever starts it doesn't create one, it won't be there? dbus-daemon creates the pid file, when configured to do so by <pidfile>/var/run/messagebus.pid</pidfile> in /etc/dbus-1/system.conf, unless run with --nopidfile. That should never have been a feature of the configuration file - it should always have been a command-line option, because sysadmins can't reconfigure it without breaking their init scripts anyway - but now that it's wrong, we can't change it, because that would break existing init scripts. The systemd unit explicitly uses --nopidfile. If someone can construct a reliable and portable way to check for an orphaned pid file, I'd review a patch. Note that on vaguely recent Linux distributions (even those not using systemd), [/var]/run should be a tmpfs; so on boot, there can never be a stale pid file there in any case.
Created attachment 106144 [details] [review] Partially revert previous commit so the tests can build This brings back the old $(static_cppflags) but renames it to $(internal_cppflags). Known regression: compilation with dbus-glib enabled is broken.
Created attachment 106145 [details] [review] Remove support for using dbus-glib for the regression tests This was an annoying circular dependency, and doesn't actually work any more now that tests are relying on being able to see private symbols in the just-compiled libdbus. Use DBusLoop unconditionally instead.
Comment on attachment 106144 [details] [review] Partially revert previous commit so the tests can build Sorry, attached this to the wrong bug :-(
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/63.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.