Bug 45713

(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.