christos@zoulas.com (Christos Zoulas)  wrote:
 > Ok, so it is selecting on fds in [0..2] and looking if it can write to
 > them. Which means that it cannot, because it would block. So what
 > are fd's 0,1,2 point to [use lsof -p 8708]? And why cannot it write?

interesting. I've never used lsof before. I built it with pkgsrc:

COMMAND  PID USER   FD   TYPE     DEVICE SIZE/OFF   NODE NAME
rsync   8708 root  cwd   VDIR        4,8      512 202752 /backup (/dev/sd1a)
rsync   8708 root  txt   VREG        4,7   136896  11828 /usr/local/bin/rsync
rsync   8708 root  txt   VREG        4,0    45369 175243 /usr/libexec/ld.elf_so
rsync   8708 root  txt   VREG        4,0   701120 151622 /usr/lib/libc.so.12.84
rsync   8708 root    1u  unix 0xc0f5054c      0t0        ->0xc0f50c84
rsync   8708 root    2u  VCHR        5,5 0t255575  41469 /dev/ttyp5
rsync   8708 root    3u  unix 0xc0ce45e8      0t0        ->0xc0f50dd4
rsync   8708 root    5u  unix 0xc0f503fc      0t0        ->0xc0f50a8c

So looks like some unhappiness with /dev/ttyp5 which is tied to an 
sshd back to an xterm on my netbsd/sparc in front of me here.  The
xterm is still speaking to me and is not blocked... I can type, and
do a ^R and that works correctly.