[OT?] kid's output stuck in a TTY?!

[Ilya Zakharevich]

I'm starting a kid, kid writes something to TTY (which is explicitely
opened in the kid). The kid also writes something to a pipe open()ed
to a parent.

parent closes the pipe opened to the kid (opened via
open F, "@kid_cmd 2>&1 |"...
). My assumption is that at this moment, all the traces of kid
existence should disappear.

However, what I observe is that the kid's output to TTY is
interdispersed with output from the next kid, and is interdispersed
with output to TTY from the parent. (Parent does not open TTY, it
just writes to STDERR which happens to be TTY.)

It looks like the output of kid is somehow "stuck" in a TTY (and it
writes whole lines!) for some time after the kid terminates. (Doing
`sleep 1' in a parent IS a workaround...)

The system is

Linux foo 2.6.18-194.3.1.el5PAE #1 SMP Thu May 13 13:48:44 TZ 2010
i686 athlon i386 GNU/Linux

Is it expected somehow?

Thanks,
Ilya

P.S. Test script is available, but it is somewhat convoluted since I
was testing for some OTHER problems. ;-) :-(

 

[Peter Makholm]

I'm starting a kid, kid writes something to TTY (which is explicitely
opened in the kid). The kid also writes something to a pipe open()ed
to a parent.

So the child process is doing something like

open my $fh, ">", "/dev/tty";

?

parent closes the pipe opened to the kid (opened via
open F, "@kid_cmd 2>&1 |"...
). My assumption is that at this moment, all the traces of kid
existence should disappear.

I would not expect closing this file handle to have eny other effect
on the child than it's STDOUT would now point to a closed pipe, which
would mean that any attempt to write to STDOUT would result in a
SIGPIPE.

I would neither expect it to kill the child process or to have eny
effect on other file handles the child process might have opened.

Is it expected somehow?

Yes, if you explicitly opens a filehandle to /dev/tty I believe this
is to be expected.

//Makholm

 

[Ilya Zakharevich]

Yes.

Closing a piped-open filehandle will wait for the child, so once close
has returned the child will have exitted. (This may of course take some
time if the child isn't killed by SIGPIPE.)

The kid just runs off the end of the script. Hmm, another thing I
missed in my description: kid writes 3 bytes to its end of the pipe
(STDOUT), and parent reads it all before close()ing.

It's not what I see here, at least with a simple test. If I run

my $K;
unless (open $K, "-|") {
warn "kid: $$";
open my $T, ">", "/dev/tty";
print $T "one two three\n";
sleep 4;
print $T "four five six\n";
exit 22;
}
close $K;
warn +($?>>8) . ": seven eight nine";

I consistently get the parent waiting for the child to finish before
continuing. Ilya: can you try that code, to see if you see the same
behaviour?

Looks normal:

kid: 2743 at ./foo.pl line 3.
one two three
four five six
22: seven eight nine at ./foo.pl line 11.

======
I put the script to
ilyaz.org/software/tmp/run_redir.pl

I run it as

perl ./run_redir.pl 1 > ! nu
perl ./run_redir.pl > ! nu

The version with 1 sleep()s, and "--"-delimited groups have duplicated
output (as expected). Without `1', "--"-delimited groups are
different, which I interpret as "--" being written at wrong order...

Puzzled,
Ilya

 

[Ilya Zakharevich]

Another thing you missed: you are forking twice (a child of a child).

Good idea! So it is the grandchild which writes to TTY, while may
implicit wait() waits for the child! No wonder that grandchild has
not yet terminate when the child does...

A lot of thanks...

AFAICT (I can't follow exactly what it's supposed to be doing)

Ha! It is just an initial prototype of a framework to test running
Perl with some of STDIN/etc closed. To make it real, I'm afraid I
need yet another parent/child layer on top of this...

Yours,
Ilya