On 12/11/2011 05:31, Guillem Jover wrote:
On Sat, 2011-11-12 at 05:21:31 +0100, Guillem Jover wrote:
On Fri, 2011-11-11 at 19:52:51 +0000, Martin Townsend wrote:
I would appreciate it if someone could confirm this is a bug and that
the fix is ok and hasn't broken anything else.
I'm running Debian lenny on an embedded arm board with a 2.6 linux OS.
W/o a reproducible case it's difficult to say if this is really a bug
in s-s-d. If you are running< 1.14.16 then that could explain it,
otherwise I don't see anything in the code to point to something else.
Just to make sure you could also try latest code from git master.
There's a bug regarding --status that I've now fixed locally, and will
be in my next push, but that should not affect your issue.
thanks,
guillem
Hi Guillem,
Thanks for the swift response. I have looked through the code some more
and see that what I am trying to do is wrong and that you need to find
the pid with check.
The first pass of the schedule will send the SIGTERM. Then during the
schedule for timeout do_stop is called with a signal of 0 so that the
call to kill will check for the existence of the pid that was retrieved
from the pidfile. This must be where it is failing for me, kill must be
returning 0 even though the pidfile has gone and ps --ef is showing that
sshd has a new process id.
I'm running dpkg version 1.14.31 but I'll try the latest code and step
through it with gdb to try and shed some light on whats going on.
Could you point me to the git master and I'll check it out on Monday?
Best Regards,
Martin.
--
Martin Townsend
Power*Oasis*
