Can I rely absolutely on what happens when a process dies.

[David Collier]

In article <20101207114353.GA15351 at xyzzy.org.uk>, bob.dunlop at xyzzy.org.uk
(Bob Dunlop) wrote:

> *From:* Bob Dunlop <bob.dunlop at xyzzy.org.uk>
> *To:* busybox at busybox.net
> *Date:* Tue, 7 Dec 2010 11:43:53 +0000
> 
> > Pid files are not very robust in general.
> 
> What he said.  However most daemons will remove their pid files 
> during
> **normal termination** and it looks like busybox dhcpc should do 
> this
> so it's been terminated abnormally. ie. Killed in some unexpected 
> way.
> So it may be worth investigation why that happened.

At the moment I'm debugging.... when it all goes wrong I have a script
which kills -9 all the orphan processes ( including OpenVPN and udhcpc )
So, yes, it isn't a mainstream real-world situation.

On the other hand I'm trying to set up shepherd scripts which will
restart dhcp, Vpp and PPP if they die when they shouldn't - and if that
ever happens, of course I may have to deal tidily with orphan pid files.

I have a testing sort of situation where a user can go to the control
screens on the unit, and change the way the comms works, then hit "action"
.... at that point I'm meant to tear down all comms, and rebuild it -
maybe turning on/off dhcp or swapping from gprs to wan as the preferred
comms route.

at the "tear down" point I will expect to stop dhcp etc. For whatever
reason we have ( very occasionally ) encountered a situation where the
PPP refused to respond to SIGINT - so the worst-case handling is not all
completely theoretical. 

D

> 
> You can make you kill script a bit more robust with a simple check. 
>  Get
> the pid from the file and examine "/proc/<pid>/cmdline" which should
> contain the name of the dhcp process as the first null terminated 
> string.
> You can't use "/proc/<pid>/exe" for this because that will just be
> pointing at busybox.  If the name matches you're on to a reasonable 
> bet
> that you are killing the right thing.
> 
> -- 
>         Bob Dunlop
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>