tags 561505 = confirmed thanks Kurt Roeckx wrote: > On Thu, Dec 17, 2009 at 09:30:48PM +0100, Michael Biebl wrote: >> Another interesting point is, why starting a second instance of hald is >> actually >> successful. >> I'm using start-stop-daemon --start --oknodo --pidfile in the init script >> which >> should prevent a second instance from being started. > > My guess would be that the pid file contains something wrong or > wasn't present.
I can confirm the problem now and roughly know what happens. The pidfile location is defined in /etc/init.d/hal and has changed between lenny and squeeze (/var/run/hal/hald.pid -> /var/run/hald/hald.pid). The old prerm script will stop the old hald instance but during the upgrade, before hal has been fully upgraded, it is restarted with the old init script (in your case this seems to happen by the dbus init script, but I have to investigate if that also can happen by the hal file trigger). The postinst of hal will then try to start hal (using the new init script), and as the pid file location has changed, start-stop-daemon will happily does so. As only one hal instance can claim the hal dbus name, the second invocation will fail with an error. Some ideas, how to address this 1.) Revert the change of the pidfile location. The reason why it was originally changed is no longer valid, so changing it back to /var/run/hal/hald.pid should be safe 2.) Before starting hal in postinst, kill any hald instance using the old pidfile. 3.) Stop restarting depended services in dbus (or at least only restart services which are actually running). See also #530000 4.) Additionally fix the hal file trigger to also only restart hal if it is actually running. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
