On Dec 10, 11:51am, hpeyerl@beer.org (Herb Peyerl) wrote:
-- Subject: Re: Was: Re: Cloning /dev/wd0 Now: rsync

| 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.

It could still be the socket at fd=1 what is on the other side of the
socket? i.e find process 0xc0f50c84 on the DEVICE column?

christos