On Wed May 14 2008 01:36:10 pm you wrote: > On Wed, May 14, 2008, Bruce Sass wrote: > > > This bug is now closed with the new dpkg; could you upgrade and > > > confirm you still have the hal bug? > > > > I can confirm the hal package fails to configure (via > > dpkg-reconfigure) if /var/run/hal/hald.pid is missing. [the hal > > bug, imo] > > Well it can happen that the missing pid files confuses hal: if you > attempt to start hal a second time because stop didn't find the pid > file and hence didn't find hal, it's normal that the second instance > may not be able to launch. The bug is that the pid file is absent > in this case IMO, and this could well be fixed by the dpkg upgrade.
The above only simulates what happens during dpkg's second (and subsequent) attempt to configure the package. The hal package (or any other package which would fail if a PID file disappeared) should be able to deal with that situation, imo. > So I suggest you clean up things manually (reboot will clear up > things) and see whether you encounter the bug again with the new > dpkg. I have no way of testing whether new code in the dpkg package can be relied upon to both remove the PID file and stop the daemon without a new hal package, and even then there is no guarantee of triggering the bug... ...I don't know when I will get the time to roll-back the hal upgrade and try again---and even then I'm not sure the bug would be triggered (based on past experience with exim [which took months and a few upgrades to gather enough data to convince the Maintainer that it was an upgrading problem] and other packages [including previous hal packages] which didn't get a report). AFAICT, this is a problem which has existed for over 4-years (see: #211784)---until s-s-d (or perhaps the new invoke-rc.d) guarantees that it will actually stop the daemon it is up to packages to deal with the situation themselves... which is why I filed the report against hal and not dpkg (and/or whatever pkg invoke-rc.d lives in). IMO, something is horribly broken if a PID file can disappear yet the daemon is left running---why would any code in its right mind rm the PID file before the daemon has stopped! The only way I can envision that happenning is if some code ASSUMES that whatever it has done will result in the daemon being stopped. Assumptions have no place in core infrastructure code (or in any computer program, but that's moot) find it and you will find the cause of these failures... if that is what the latest dpkg package has done then I look forward to not having to, occasionally, manually kill processes to get a clean upgrade. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
