On 26.11.2014 16:55, Timo Aaltonen wrote: > On 22.11.2014 16:35, Simon McVittie wrote: >> On Thu, 13 Nov 2014 at 23:30:00 -0800, Cameron Norman wrote: >>> On Thu, 13 Nov 2014 17:59:51 +0100 Benjamin Drung >>> <benjamin.dr...@profitbricks.com> wrote: >>>> Setting up certmonger (0.75.14-2) ... >>>> Failed to issue method call: Unit dbus.socket failed to load: No such file >>> or directory. >>>> invoke-rc.d: initscript certmonger, action "start" failed. >>>> [...] >>>> certmonger should probably depend on dbus. >>> >>> Please do not do that. Both the Upstart job and init script work just fine >>> without D-Bus installed. >>> >>> Instead, I think that the certmonger systemd service should change its type >>> from dbus to forking and remove the `-n` option. Alternatively, it could use >>> Type=simple and keep the `-n` option but then you do not get readiness. Not >>> sure if that is critical. >> >> If you don't want to depend on dbus then changing the Type to forking >> (and removing the -n option) seems best. The service already has the >> necessary PIDFile= line to be able to tell systemd which of its processes >> after forking is to be considered the main one. > > I'll ask upstream why the change to dbus type was made in
"I thought it'd be friendlier to note that the daemon acquires a service name at startup. The shutdown problem we were seeing around then turned out to be more about the .path unit being a bad idea than anything in the .service file. The package does need D-Bus -- getcert and other clients need the bus to be around in order to pass requests along to the daemon, and the daemon will fail to start if it can't connect to the bus. The Type=dbus setting tells systemd that the bus needs to be running before it tries to start the service, and I suppose that information would be lost if the Type changed. To prevent failures due to that run-time dependency no longer being known and accounted for, the dependency would have to be expressed in some other way." So that explains it, adding dbus to depends is the way to go even if the unit file would be changed (which it won't). -- t -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org