Quoth Philip Hazel on Wed, May 26, 1999:
> An exim queue-runner is supposed to do serial delivery, one message at a
> time. If it starts up a process that delivers down an SMTP channel, and
> that process hands the open channel on to a 3rd process and then exits,
> the queue runner must not continue until the 3rd process has finished.
Why is the second process created the third process and exits?
Even if it's needed to exec exim, why fork before that?
> The 3rd process is not the queue runner's own child, so it can't wait
> for it directly. Or can it? Perhaps some Unix guru will be able to tell
> me I am being silly here.
Well, AFAIK, there's no way to wait for your grandchild. Some
other possibilities exist, e.g., before Q (the queue runner)
forks process B, it can create a pipe from B to Q, and when B
forks C, C will get the write end of the pipe from B. When C
dies, the pipe is closed, and Q will get an EOF on it. So when Q
has nothing to do, it can select(2) on the pipe.
Granted, it's dirty. Yet another possibility is that C before
exiting will send a signal to Q. The downside is that if C is
nuked, Q will get no signal, so Q should poll C from time to
time.
Anyway, I don't know why you HUP the processes. Can you send the
signal 0 (i.e., just use kill(2) to check if the process exists)
instead?
> Process A creates process B; process B creates process C and exits;
> process C creates process D and exits, .... to some number of
> processes. Process A wants to wait until all the descendents have
> completed. It can get the list of process ids (by reading a file).
A-ha. So the fork chain can be longer than even two forks...
All the solutions above will still work (dirtily), but anyway,
why do you need far descendents?
Vadik.
--
Do not meddle in the affairs of troff, for it is subtle and quick
to anger.
--
*** Exim information can be found at
http://www.exim.org/ ***
