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

Denys Vlasenko vda.linux at googlemail.com
Tue Dec 7 11:04:15 UTC 2010


On Tue, Dec 7, 2010 at 11:26 AM, David Collier
<from_busybox_maillist at dexdyne.com> wrote:
> I am struggling a bit with locating and sending signals to processes like
> udhcpc.
>
> I enabled the "write your pid to this file" option... but of course the
> file persists after the process dies... so if you look in the file for a
> pid... and some other process has started up in the meantime with the
> SAME pid, you will send your signal to the wrong flipping process.
>
> IN THE SHORT TERM.... my way around this could be to write a small script
> such as
>
>   # -f means "don't fork"
>   udchpc ......... -f -pidfile /tmp/fred
>   # we will only get here when udhcpc has ended
>   rm /tmp/fred
>
> My question is - can I rely completely on the principle that no matter
> how udhcpc comes to an end ( exit, seg fault, OOM handling whatever ) the
> script will be resumed ( provided OOM hasn't got to it ) , and the rm
> command executed?

Unless the shell which executes the script is killed.
While udchpc runs, shell (it's parent process which executes the script)
waits for udchpc to terminate. It (shell) can be killed.
This doesn't affect udhcpc, but anything after it in the script won't run.

Pid files are not very robust in general.

What are you trying to achieve on a bigger scale?
(I mean, using the pid from pidfile is an element of some
bigger plan of yours. What is it?)

-- 
vda


More information about the busybox mailing list