Created attachment 266001 [details, diff] patch to files/dbus-init-1.0 to ensure stale pid files cleaned up With at least sys-apps/dbus-1.4.6 (and possibly other versions, eg see bug #348072), dbus will not start if the pid file exists (eg left over due to crash or killed process). I suspect the user in the referenced bug simply restarted their machine and the boot scripts cleaned /var/run, hence they didn't notice that the problem still existed? Additionally in dbus-1.4.6 I don't see the pid file removed when dbus shuts down... This means that a simple "/etc/init.d/dbus restart" fails... I suspect that this may be a permission issue because a) dbus drops privs after starting, b) creates the pid file in /var/run with root ownership, c) when it shuts down I should imagine it lacks privs to remove the pidfile? There is already a section of the init.d file which removes the stale command socket, so I suspect the pidfile being leftover is really just the same? I have attached a patch for the init script which is fairly tame and should fix this permanently without causing any issues if upstream improve things. My patch removes the pidfile at shutdown and checks for a stale pid (and removes it) at startup. Grateful if someone could please apply to files/dbus-init-1.0
CCing OpenRC maintainers because the first impression I'm getting here is that OpenRC should cleanup stale pid files on it's own, and this shouldn't go into <random> init scripts Any thoughts?
In fact, since `emerge --info` is missing in the bug, this might be a case for RESOLVED, NEEDINFO. As we don't even know if the reporter is using BL-1 or BL-2.
(In reply to comment #1) > CCing OpenRC maintainers because the first impression I'm getting here is that > OpenRC should cleanup stale pid files on it's own, and this shouldn't go into > <random> init scripts > > Any thoughts? 17:42 < WilliamH> Openrc does try to clean up stale pid files btw. 17:43 < WilliamH> Look at bootmisc 17:44 < WilliamH> Also look at s-s-d.c (In reply to comment #2) > In fact, since `emerge --info` is missing in the bug, this might be a case for > RESOLVED, NEEDINFO. > > As we don't even know if the reporter is using BL-1 or BL-2. Do reopen with `emerge --info` if the problem still persists with latest baselayout-2/openrc. Also once we get /run properly set up, tmpfs will always be mounted there, making the bug irrelevant (if it already isn't)
*** This bug has been marked as a duplicate of bug 231854 ***
<mystic handwaving> You don't need to see my emerge --info... This is not the type of bug you are looking for... </mystic handwaving> I don't see what buttons I need to push to reopen a bug on here? Can someone please re-read my problem report and re-open it? The problem report has been misread and closed it for the wrong reason? To highlight the misunderstanding: "bootmisc" runs at startup. The problem report states that "/etc/init.d/dbus restart" fails.... Running at startup once bootmisc has run is fine and dandy, restarting hostapd after boot is what goes wrong... I think because hostapd isn't restarted all that often (except at boot), the problem hasn't been widely noticed. Note my exact same point in the original problem report that bootmisc is fixing things on boot, but it's the restart of the process which is failing? FWIW: Baselayout 2, Openrc (whatever was unmasked a couple of months ago - 0.8.2 I think?). However, I'm pretty sure this is a problem with hostapd, something we need to fixup in the init scripts and hence absolutely nothing to do with BL/Openrc, so please lets ignore BL/Openrc wrt this bug Please commit the fix above or describe a better fix? Thanks
Ahh cr*p, got hostapd on the brain... Please s/hostapd/dbus/ in the previous comment
please actually read the bug this has been marked as a duplicate of. adding hacks to random init.d scripts is not the way to go for fairly obvious reasons.
Well, up until William Hubbs potential solution, I had read the bug and natural progression was a bunch of bugs raised against specific packages... However, although I haven't tested his solution it looks better than mine - can all eyes now look at the latest patch in bug: #231854 Please can we move to (test and) commit *that* quickly and this patch can remain closed. Thanks
the availability of a patch is irrelevant. the point is to fix things the right away and not hack away individual packages.
The availability of an *idea* to fix things is relevant though! The idea to patch openrc is new and wasn't available at the point I wrote my comment? Having considered the idea in bug:231854 further, it still needs some "hacking away at individual packages"... It relies on a $pidfile variable being set in the init.d file. This isn't present in dbus-1.4.6, but presumably isn't objectionable to add it? So, I hope someone can add further debate on bug: 231854 and comment as to whether it is actually the best fix? However, if it's deemed "correct", then this bug still needs to be re-opened to add the first hunk of the patch I gave: --- a/files/dbus.init-1.0 2007-04-04 14:35:25.000000000 +0100 +++ b/files/dbus.init-1.0 2011-03-15 17:22:08.000000000 +0000 @@ -4,6 +4,7 @@ # $Header: /var/cvsroot/gentoo-x86/sys-apps/dbus/files/dbus.init-1.0,v 1.4 2007/04/04 13:35:25 cardoe Exp $ opts="reload" +pidfile="/var/run/dbus.pid" depend() { need localmount Perhaps someone can just commit this first line since it is otherwise benign and causes no offence... Thanks
didnt mean to undupe ... keep all the discussion in the one place. no sense in splitting across multiple reports. *** This bug has been marked as a duplicate of bug 231854 ***
