named pipes blocking zsh

named pipes blocking zsh

[Tim K. (Gmane)]

Hello,

I have a situtation with zsh: I use pine as my mail reader and it has a 
feature where it can create a named pipe (FIFO) and write to it when new 
mail arrives. Naturally, I thought of writing a script at the other end 
of the pipe that reads the messages and sends me notifications in some 
other way.

The way I have it set up is to have a zsh script that starts another 
"notify" child zsh script that reads from the pipe and does its 
notification thing and then the main script calls pine.

This all seems to work, except when I quit pine, hence terminating the 
main "parent" script, the child "notify" script does not exit, it's 
stuck reading from the pipe (even though the pipe is deleted). The child 
script becomes owned by PPID 1 and the only way to kill it is kill -9 ...

I'm reading with the built in "read var < pine_pipe" which blocks until 
the first line of data is written to the pipe by pine. I also tried 
"read -t" but it doesn't react to the timeout. Also tried the zselect 
module, with and without timeouts, nothing works. If there's nothing in 
the pipe, the zsh process just hangs until there is data.

My current workaround is to trap the exits from the main script and kill 
-9 the child script. This works fine almost all the time except when the 
main script itself is killed and it doesn't have a chance to kill it's 
child. For this I made the notify script clean up any running instances 
of itself when it comes up (but there's still that window of time where 
there's a zsh process around that refuses to die).

Is there anything in particular I should be aware of with these named 
pipes? I'm using zsh 4.2.1 if it makes a difference ...

Thanks for your help.

-- 
Tim

Re: named pipes blocking zsh

[Bart Schaefer]

On Jun 1,  7:18am, Tim K. (Gmane) wrote:
}
} I have a situtation with zsh: I use pine as my mail reader and it has a 
} feature where it can create a named pipe (FIFO) and write to it when new 
} mail arrives.
} 
} This all seems to work, except when I quit pine, hence terminating the 
} main "parent" script, the child "notify" script does not exit, it's 
} stuck reading from the pipe (even though the pipe is deleted).

I think this qualifies as a pine bug.  Removing a named pipe will not
by itself send an EOF to any processes that are listening on it.  The
right way for pine to shut down the connection would be to open the fifo,
remove the disk file, then send a final EOF by closing the descriptor.

Anything else is a race condition with the listening process, which may
re-open the fifo for reading before pine has removed it.

Re: named pipes blocking zsh

[Peter Stephenson]

"Tim K. (Gmane)" wrote:
> I have a situtation with zsh: I use pine as my mail reader and it has a 
> feature where it can create a named pipe (FIFO) and write to it when new 
> mail arrives. Naturally, I thought of writing a script at the other end 
> of the pipe that reads the messages and sends me notifications in some 
> other way.
> 
> The way I have it set up is to have a zsh script that starts another 
> "notify" child zsh script that reads from the pipe and does its 
> notification thing and then the main script calls pine.
> 
> This all seems to work, except when I quit pine, hence terminating the 
> main "parent" script, the child "notify" script does not exit, it's 
> stuck reading from the pipe (even though the pipe is deleted). The child 
> script becomes owned by PPID 1 and the only way to kill it is kill -9 ...
> 
> I'm reading with the built in "read var < pine_pipe" which blocks until 
> the first line of data is written to the pipe by pine. I also tried 
> "read -t" but it doesn't react to the timeout. Also tried the zselect 
> module, with and without timeouts, nothing works. If there's nothing in 
> the pipe, the zsh process just hangs until there is data.

I'm not sure how much the shell can do about this...

The shell is actually blocking in the "open" call to pine_pipe, not in
the builtin itself.  This is the way reading from pipes works: you can't
open the pipe until someone is writing to it.  If the open fails, it's up
to the system to tell the shell, which will find out as soon as the call
returns, and can't very well find out it before.

It's possible to open without blocking, but that's not actually what you
want:  you need to blocking behaviour to be able to open the pipe when
the other side writes to it.

I can't offhand think of a simple solution.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: named pipes blocking zsh

[Tim K. (Gmane)]

What's interesting is that if I 'strace' the zsh process while it's 
stuck (after the pipe was deleted), it will terminate. I'm not sure what 
the explanation behind it is ...

Thanks.

Tim



Bart Schaefer wrote:

>On Jun 1,  7:18am, Tim K. (Gmane) wrote:
>}
>} I have a situtation with zsh: I use pine as my mail reader and it has a 
>} feature where it can create a named pipe (FIFO) and write to it when new 
>} mail arrives.
>} 
>} This all seems to work, except when I quit pine, hence terminating the 
>} main "parent" script, the child "notify" script does not exit, it's 
>} stuck reading from the pipe (even though the pipe is deleted).
>
>I think this qualifies as a pine bug.  Removing a named pipe will not
>by itself send an EOF to any processes that are listening on it.  The
>right way for pine to shut down the connection would be to open the fifo,
>remove the disk file, then send a final EOF by closing the descriptor.
>
>Anything else is a race condition with the listening process, which may
>re-open the fifo for reading before pine has removed it.
>
>  
>

Re: named pipes blocking zsh

[Tim K. (Gmane)]

Now that I think about it, what if the pine process crashed and didn't 
have a chance to send an EOF or remove the pipe (assuming pine 
implemented the EOF)? It seems that the read with timeout in zsh should 
work, it should not just block forever even though a timeout is 
specified, but maybe it's not possible to do because it's stuck in 
open() not in a read call.

Thanks.

>
>I think this qualifies as a pine bug.  Removing a named pipe will not
>by itself send an EOF to any processes that are listening on it.  The
>right way for pine to shut down the connection would be to open the fifo,
>remove the disk file, then send a final EOF by closing the descriptor.
>
>Anything else is a race condition with the listening process, which may
>re-open the fifo for reading before pine has removed it.
>
>  
>

Re: named pipes blocking zsh

[Peter Stephenson]

"Tim K. (Gmane)" wrote:
> What's interesting is that if I 'strace' the zsh process while it's 
> stuck (after the pipe was deleted), it will terminate. I'm not sure what 
> the explanation behind it is ...

Presumably to be able to trace the system call there is a different
pathway through the open() call.

pws


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: named pipes blocking zsh

[Bart Schaefer]

On Jun 1,  8:24am, Tim K. (Gmane) wrote:
}
} Now that I think about it, what if the pine process crashed and
} didn't have a chance to send an EOF or remove the pipe (assuming pine
} implemented the EOF)?

A crash that severe is by definition an unrecoverable error; it's not
possible to write code to handle it, and it's certainly not zsh's job
to attempt to handle unrecoverable errors in other arbitrary programs.

On Jun 1,  8:20am, Tim K. (Gmane) wrote:
} Subject: Re: named pipes blocking zsh
}
} What's interesting is that if I 'strace' the zsh process while it's 
} stuck (after the pipe was deleted), it will terminate.

That's almost certainly because strace sends a SIGPROF to zsh, which
interrupts whatever system call was blocking on the fifo.

I suspect that if you attempted something other than "kill -9" (such as,
say, "kill -1") you'd find that it *is* possible to politely interrupt
zsh when it's waiting on the fifo.