[Pkg-utopia-maintainers] Bug#480552: fails to stop hald on upgrade...

[Bruce Sass]

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