Re: Questions about perl daemons with child processes and open files / signals

"none" <mikem891@xxxxxxxxxxx> wrote:
Thanks Xho,

You say that that open doesn't return control to the script (which I
can not replicate on my machine) yet that open is exactly what you use
in starttcpdump(). Are you saying it does return control when used in
the child, but not when used in the parent?

Sorry it wasn't clear, I didn't mean in this code, but if I don't use
fork to
process the pipe in the child process. For exemple if I do this in the
parent
process:

open PIPE, "pipeapp |";
# never return here until pipeapp terminates.

Are you sure? Are you perhaps confusing the hanging upon close (which
we just solved) with this supposed hanging on open?

warn time(), " I'm about to open pipe, do I return control?"
open my $fh, "pipeapp |" or die $!;
warn time(), " yes, I really did just open the pipe and return control!"
## Or print on an unbuffered handle, but I like warn


Why is there a parent process at all at this point? The parent doesn't
seem to have anything useful to do, so why not exit rather than hanging
around in a waitpid?

A this point the parent is the main script, no?

No. The parent sits in the waitpid, waiting for the child to exit. But
before the child exits, the last thing it does is kill the parent. So the
parent should never get past the waitpid statement. In which case, turn
the waitpid into an exit. (Or don't do this fork at all, I'm still not
convinced that it is necessary.)

So it should continue
to
execute and go to the endless loop to process the pipe data.

The parent doesn't have access to the pipe data. Only the child does.
This is why, when you got rid the waitpid, you got a bunch of file-handle
warnings. The parent and child both returned from starttcpdump and fell
into the infinite loop. When the parent did so, it tried to read from
a handle that it never opened. The child, of course, had no such problems.


I think I
tried it without the waitpid and it didn't work. Or I'm I completly
lost and
just create another useless parent?
while (1)
{
# do something
}

I think you are confused about who executes this loop. As your code is
written, your child falls into this loop. The parent doesn't, because the
parent gets stuck at waitpid until it is killed. When you remove the
waitpid, then both the parent and the child fall into this loop.



So it hangs upon the open if you don't fork and upon the close if you
do fork? What OS are you using?

OpenBSD 3.8

Sorry, I don't have access to that, so I can't test the OS-specific
aspects.

By the way, this morning I made some experimentations with threads and
found out that my perl is not compiled with threads enabled. So I think
I'll
stick with forks since I do not want to recompile it and the code will
be
more portable. I still think forks in my case are a useless memory
waste
for such a simple thing as running a background pipe.

I don't think you really need the forks (other than the one in
createdaemon).

If I had to guess, I'd say: That on your OS, tcpdump takes a long
time to realize that nothing was on the other end of the pipe after the
reading perl script exits (or maybe it never realizes it, but it is
somewhat hard to believe that--a OS with that bug would probably become
unusable in short order, with all these moribund processes piling up behind
SIGPIPEs.) You introduced the fork to solve that problem, but it didn't
really solve it. Now you have solved that problem, but you
misremembered/misinterpreted why you introduced the fork in the first
place.

I would not worry about the computer memory wasted due to unnecessary
forking, it is probably negligible. I would worry about the human
confusion caused by unnecessary forking!

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
.

Relevant Pages

  • Re: continuous write to hard disk
    ... | herd" problem and the only cause for scheduling latency with the O ... Parent sets up some shared memory. ... Parent sets up pipes and forks child B. ... Child B blocks in readon pipe for message from parent. ...
    (comp.os.linux.development.system)
  • Re: Python, Tkinter and popen problem
    ... but that is not `both way': popen connects the parent to the child ... The pipe works one way: from the child to the parent ... A child process always inherits stdin, stdout and stderr from the parent ...
    (comp.lang.python)
  • Re: Forking
    ... On Wednesday 03 March 2004 20:47, Price, Jason generously enriched virtual ... pipe takes two filehandles: ... inherit filehandles of the parent process as a copy. ... waits for the child to teminate and returns its pid once it died. ...
    (perl.beginners)
  • pipe from child to parent: the parent exits, but the child does not
    ... Each child writes then the 3 fetched int values ... via the pipe to the parent. ... So I have prepared a simple test case program, which forks NKIDS ...
    (comp.unix.programmer)
  • Re: waitpid
    ... > What's the point of waitpid with WNOHANG and the value ... > child process has not terminated, ... will terminate and since you don't want to block ... the parent can continue to do his work. ...
    (comp.unix.programmer)
Loading