Re: [rdiff-backup-users] rdiff-backup crash

[Ben Escoto]

>>>>> Martin Pool <address@hidden>
>>>>> wrote the following on Mon, 17 May 2004 16:58:59 +1000

> You should only see EAGAIN on a file descriptor in nonblocking mode.
> This can sometimes happen on programs invoked over SSH.  In this case
> the fd is a pipe or unix domain socket connecting the rdiff-backup
> server to the sshd child.  So EAGAIN (aka EWOULDBLOCK) will happen
> when rdiff-backup produces output faster than sshd can consume it.  As
> you might expect lowering the terminal verbosity fixes that.
> 
> So there are basically two things you can do:
> 
> 1 - Check for EAGAIN; when you get it then select() on the socket and
> retry.  Presumably a good way in Python is to just use a little
> decorator object around the real file.
> 
> 2 - Make the socket nonblocking.  But I don't know if that would upset
> sshd.

(As Dean Gaudet noted, presumably you mean "blocking" for #2.)  But
why would stdout be in non-blocking mode to begin with?  Clearly on
most systems it's in blocking mode, or else almost every instance of
rdiff-backup would fail (because the server side is often writing to
stdout as fast as it can).

When rsync is writing to stdout when run over a pipe, do you remember
if it fcntls stdout to make sure it is blocking?

Also, and this may be an important clue, sshd may not have started the
crashed process in Dave Hawkes's example.  It was the client that
crashed when trying to write to stdout, so stdout was most likely
connected to a terminal.

If Dave is still interested, perhaps he could tell us what kind of
system he has and how rdiff-backup is run on it.


-- 
Ben Escoto

pgprYNM75vCDK.pgp
Description: PGP signature