I'd appreciate a bit of confirmation of my understanding of tar behavior. We (the Amanda team) have a user who is seeing SIGPIPE when verifying a dump using 'tar -tf -'. A truss (yep, it's Solaris..) shows the tar process happily munching data at 10k per go, and outputting filenames:
10350: read(0, 0x080AA000, 10240) = 10240 10350: write(1, 0x080AE034, 114) = 114 10350: write(1, 0x080AE034, 121) = 121 ... (actual data omitted to protect the innocent) Then, without warning, and without seeing any EOF or even a short read on fd 0, tar up and exits cleanly: ... 10350: write(1, 0x080AE034, 98) = 98 10350: read(0, 0x080AA000, 10240) = 10240 10350: write(1, 0x080AE034, 102) = 102 10350: write(1, 0x080AE034, 14) = 14 10350: close(0) = 0 10350: close(1) = 0 10350: close(2) = 0 10350: _exit(0) and, of course, the Amanda process writing to the other end of the pipe gets SIGPIPE. I believe, but have not verified with the user, that this occurs at the end of the tarfile. Amanda (well, the tape drive really) pads the tarfile out with zeroes to a multiple of the block size (32k). My understanding is that tar should keep running until it gets EOF on its input - that there's no explicit indication within a tarfile that would cause tar to exit normally without reading to EOF. A bit of experimentation with /dev/zero on my own systems lends credence to this understanding, but of course does not prove it: (tar -cf - ChangeLog; cat /dev/zero) | tar -tf - ChangeLog (this hangs forever here, and truss or strace shows tar reading a lot of 0's without any _exit(0) action..) If there's something I've missed about tar's behavior, or if you have any other suggestions, please share! Dustin -- Open Source Storage Engineer http://www.zmanda.com
