PERL Miscellaneous - named pipe and "Text file busy"

Author

named pipe and "Text file busy"

mikexf@gmail.com

2007-11-24, 10:09 pm

Hi There,

I've got a PERL script which runs on linux and spawns a thread which
opens a FIFO pipe in read only mode. I use a different program to
write data to FIFO (written in c or simple echo command). Works like a
charm, however once I exit the script (via CTRL-C) and restart it, the
pipe becomes unusable for writing (i.e. no program is able to open it
for writing - they get back en error message: errno 26 "Text file
busy"). I need to create another FIFO in order for me use the script
again.
Internally I catch CTRL-C signal and close the FIFO explicitly.

What's wrong? Is it because I have 2 threads running i.e. one does
some other processing and the second one is responsible for the pipe??
What's the correct and clean way to exit from multithreaded program in
Perl? Or is it another issue? Any help would be greatly appreciated.

Thanks, finpro

Ben Morrow

2007-11-25, 4:28 am

Quoth mikexf@gmail.com:
>
> I've got a PERL

Perl. Spelling is important.

> script which runs on linux and spawns a thread which
> opens a FIFO pipe in read only mode. I use a different program to
> write data to FIFO (written in c or simple echo command). Works like a
> charm, however once I exit the script (via CTRL-C) and restart it, the
> pipe becomes unusable for writing (i.e. no program is able to open it
> for writing - they get back en error message: errno 26 "Text file
> busy"). I need to create another FIFO in order for me use the script
> again.

That's bizarre. Attempting to write to a pipe which isn't open for
reading should raise SIGPIPE, and if that is caught the write should
fail with EPIPE. Are you *sure* this is what's happening? What happens
if you run this Perl program to write to the pipe:

#!/usr/bin/perl -l

use strict;
use warnings;

use Errno;

$SIG{PIPE} = sub { warn "got SIGPIPE" };

open my $P, '>', 'pipe'
or die "can't open pipe: $!";

while (1) {
print $P 'foo'
or warn "print failed: $!";
sleep 2;
}

__END__

> Internally I catch CTRL-C signal and close the FIFO explicitly.

This shouldn't make any difference: the fifo is closed when your program
exits anyway.

> What's wrong? Is it because I have 2 threads running i.e. one does
> some other processing and the second one is responsible for the pipe??

Again, shouldn't make any difference.

Ben

alexfayn@gmail.com

2007-11-28, 8:04 am

> That's bizarre. Attempting to write to apipewhich isn't open for
> reading should raise SIGPIPE, and if that is caught the write should
> fail with EPIPE. Are you *sure* this is what's happening? What happens
> if you run this Perl program to write to thepipe:
>

If i just create a new pipe and there's no script (reader) running,
then the program blocks.
If i've got the script running later - it will read 'foo' from the
pipe. However after i kill the script and then
run this program again (it does not matter whether i start the reader
this time, the behavior is identical with either my Perl script
running or stopped) the program can't write and reports an error "Text
file busy"

Thanks

Ben Morrow

2007-11-28, 7:07 pm

Quoth alexfayn@gmail.com:
>
> If i just create a new pipe and there's no script (reader) running,
> then the program blocks.
> If i've got the script running later - it will read 'foo' from the
> pipe. However after i kill the script and then
> run this program again (it does not matter whether i start the reader
> this time, the behavior is identical with either my Perl script
> running or stopped) the program can't write and reports an error "Text
> file busy"

This is very odd: the only way you're supposed to be able to get ETXTBSY
is by trying to write to a file that's currently being executed. Can you
write a trivial reader program in C and try that instead? If that fails
then your problem is with your OS or your filesystem, not with Perl. If
not, can you tell us

1. which version of Linux you are using

2. what type of fs the fifo is being created on

3. an exact recipe to reproduce the problem, preferably in the form
of a minimal script that creates a fifo, forks and attempts to talk
to itself.

Ben

Sponsored Links