On Thu, Aug 5, 2010 at 2:57 PM, Sean Walmsley <s...@fpp.nuclearsafetysolutions.com> wrote: > It looks to me like: > > - process 10344 (amcheckdump) creates a pipe > with file descriptors 8 and 9 at each end. > - the process forks off a child (10350) > - the parent closes fd8 > - the child closes fd9 and eventually dups > fd8 onto fd0 (std in)
Nice work! You'll also notice this absolutely brain-dead behavior by good 'ol Perl: 10350: dup(8) = 9 10350: fcntl(8, F_GETFD, 0x082320DC) = 1 10350: dup(8) = 11 10350: llseek(8, 0, SEEK_CUR) Err#29 ESPIPE 10350: close(8) = 0 10350: fcntl(11, F_DUP2FD, 0x00000008) = 8 10350: close(11) = 0 10350: fcntl(9, F_DUP2FD, 0x00000008) = 8 10350: fcntl(8, F_SETFD, 0x00000001) = 0 10350: close(9) = 0 which is the long way 'round the barn to accomplish, well, nothing really. However, you'll note that it is thread-unsafe! In particular, if some other thread happens to open a new file descriptor 8 between close(8) and dup2(11, 8), then that thread's file descriptor will get clobbered. This behavior is only invoked when running on Sun's libc (Solaris and, I've learned, Nexenta), but sadly it's going to force us to reimplement the entire perlio layer. Anyway, enough ranting for now. That's not actually causing the problem here as far as I can tell. > Eventually, (line 4461) the child seems to exit normally with > exit status of 0. It looks to me like this is an orderly > exit with normal cleanup, closing of file descriptors, etc. This is an accurate description, and I don't see anything in the truss output that you missed. I just don't know why tar quits! It hasn't gotten *any* indication that it is nearing EOF, not even a short read: 10350: read(0, 0x080AA000, 10240) = 10240 To my knowledge, GNU tar will not exit before it gets EOF. In fact, we depend on GNU tar to happily digest a lot of trailing zeroes on dumpfiles, since some devices (tapes) pad the end of a file with zeroes. What does cat /dev/zero | /usr/sfw/bin/gtar -tf - do for you? On my Solaris 10 system, it runs forever, and a truss shows tar reading 0's in 10k increments without any output. I even tried concatenating zeroes onto a real tarfile, with the same result: (tar -cf - test; cat /dev/zero) | /usr/sfw/bin/gtar -tf - I'll check on the GNU Tar list, but let me know what you find. Dustin -- Open Source Storage Engineer http://www.zmanda.com
