Well, I have been busy getting child #4 off on her way to college (joining #2). So now it is quite with just the 2 youngest and I can get work done again!. tar stops as follows: /root/.nautilus/metafiles/x-nautilus-desktop:%2F%2F52F.xml tar: Error exit delayed from previous errors. I thought perhaps this is some file locked becuase I was running from a terminal session in gnome. So I switched over to init 3 and ran the tar process from the text session. Still got this error. How do I figure out what is wrong and how do I find any similar show-stoppers?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Moskowitz wrote:> So I switched over to init 3 and ran the tar process from the text session. > > Still got this error. > > How do I figure out what is wrong and how do I find any similar > show-stoppers? >That error is frequently caused by a lock or with the file changing while being backed up. Use the verbose option with tar, then scan down through the log to find out what happened. If you have a non-fatal error early on in the execution of tar you'll receive notice of it at the end of execution. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFFBsJsCFu3bIiwtTARAi06AKCSoSMXUS91lxDsQvOUQklnykDJSgCeNJLX FAt1KNtH5GklMOHuQE60bjo=WMcA -----END PGP SIGNATURE-----
Barry L. Kline wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Robert Moskowitz wrote: > > >> So I switched over to init 3 and ran the tar process from the text session. >> >> Still got this error. >> >> How do I figure out what is wrong and how do I find any similar >> show-stoppers? >> >> > > That error is frequently caused by a lock or with the file changing > while being backed up.thought so.> Use the verbose option with tar, then scan down > through the log to find out what happened.Used verbose mode. That is why everything escrowed of the screen.> If you have a non-fatal > error early on in the execution of tar you'll receive notice of it at > the end of execution. >Never got to the end of execution. Had lots of files still to go.
Will McDonald wrote:> On 12/09/06, Barry L. Kline <blkline at attglobal.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Robert Moskowitz wrote: >> >> > So I switched over to init 3 and ran the tar process from the text >> session. >> > >> > Still got this error. >> > >> > How do I figure out what is wrong and how do I find any similar >> > show-stoppers? >> > >> >> That error is frequently caused by a lock or with the file changing >> while being backed up. Use the verbose option with tar, then scan down >> through the log to find out what happened. If you have a non-fatal >> error early on in the execution of tar you'll receive notice of it at >> the end of execution. > > I'd send STDOUT and STDERR to separate logs for brevity's sake. > Something like... > > tar czvf $destfile $tobetarred > /tmp/tarlog.std 2> /tmp/tarlog.errDoubt if it would be for brevity sake, rather the ablity to see all that happened! And forgot about standerr....
Ralph Angenendt wrote:> Will McDonald wrote: > >> I'd send STDOUT and STDERR to separate logs for brevity's sake. >> Something like... >> >> tar czvf $destfile $tobetarred > /tmp/tarlog.std 2> /tmp/tarlog.err >> > > If you want to have it brief - why the "v"? >Becuase then at least I might see what files were being processed when the tar stopped?
Will McDonald wrote:> On 12/09/06, Barry L. Kline <blkline at attglobal.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Robert Moskowitz wrote: >> >> > So I switched over to init 3 and ran the tar process from the text >> session. >> > >> > Still got this error. >> > >> > How do I figure out what is wrong and how do I find any similar >> > show-stoppers? >> > >> >> That error is frequently caused by a lock or with the file changing >> while being backed up. Use the verbose option with tar, then scan down >> through the log to find out what happened. If you have a non-fatal >> error early on in the execution of tar you'll receive notice of it at >> the end of execution. > > I'd send STDOUT and STDERR to separate logs for brevity's sake. > Something like... > > tar czvf $destfile $tobetarred > /tmp/tarlog.std 2> /tmp/tarlog.errWait a sec here. I am piping the tar to stdout (tar czvfO ) then sending that through to SSH ( | SSH ....) to be cated into the actual file ( cat > archive.tgz): tar -cpvzO / --exclude-from=/home/not-file | ssh user at ipaddrs "cat > backup.tgz" So where is the verbose going to so I see it on the screen? STDERR? And still either how do I unlock any locked files left locked by X? And/or just tar them with the lock?
Will McDonald wrote:> On 12/09/06, Ralph Angenendt <ra+centos at br-online.de> wrote: >> Will McDonald wrote: >> > I'd send STDOUT and STDERR to separate logs for brevity's sake. >> > Something like... >> > >> > tar czvf $destfile $tobetarred > /tmp/tarlog.std 2> /tmp/tarlog.err >> >> If you want to have it brief - why the "v"? > > Pedant. :) > > What I *meant* was then all the errors would be in one place, all the > standard messages in an other, which is kinda brevity.OK. I used the following: tar -cpvzO / --exclude-from=/home/not-file 2>/tmp/tarlog.err | ssh user at ipaddrs "cat > backup.tgz" No messages went to the screen. tarlog.err is 4Mb large. Looked at it for error messages. NONE! not even the one I was getting before routing stderr.out. I did a the -l option, but that should not result in no error messages... So now what? Confused.
Les Mikesell wrote:> On Tue, 2006-09-12 at 12:00 -0400, Robert Moskowitz wrote: > >>> >>> >>>> I'd send STDOUT and STDERR to separate logs for brevity's sake. >>>> Something like... >>>> >>>> tar czvf $destfile $tobetarred > /tmp/tarlog.std 2> /tmp/tarlog.err >>>> >>>> >>> If you want to have it brief - why the "v"? >>> >>> >> Becuase then at least I might see what files were being processed when >> the tar stopped? >> > > Tar shouldn't have stopped regardless of complaints about files that > are unreadable or disappear. If you are sure it isn't completing > try running it with 'strace' and look at the system errors when > it dies.Sounds reasonable. Had to lookup up strace. So I would run: starce -o /tmp/strace.log tar -cpvzO / --exclude-from=/home/not-file 2>/tmp/tarlog.err | ssh user at ipaddrs "cat > backup.tgz" ?
Les Mikesell wrote:> On Tue, 2006-09-12 at 12:48 -0400, Robert Moskowitz wrote: > > >>> Tar shouldn't have stopped regardless of complaints about files that >>> are unreadable or disappear. If you are sure it isn't completing >>> try running it with 'strace' and look at the system errors when >>> it dies. >>> >> Sounds reasonable. Had to lookup up strace. >> >> So I would run: >> >> starce -o /tmp/strace.log tar -cpvzO / --exclude-from=/home/not-file >> 2>/tmp/tarlog.err | ssh user at ipaddrs "cat > backup.tgz" >> > > Spell it right.. But I think I'd try to narrow down the set of files > that make tar stop before you think it should and do something simple > like: > strace tar cf /dev/null file1 file2 file3 > and look at the return values on the system calls affecting these > files. But, my first guess is that your excludes aren't working > the way you expect and you are wandering into /proc. >I will have to study this a bit. And I checked my tarlog.err file and no /proc entries.
Les Mikesell wrote:> On Tue, 2006-09-12 at 12:35 -0400, Robert Moskowitz wrote: > > >> tar -cpvzO / --exclude-from=/home/not-file 2>/tmp/tarlog.err | ssh >> user at ipaddrs "cat > backup.tgz" >> >> >> No messages went to the screen. tarlog.err is 4Mb large. Looked at it >> for error messages. >> >> NONE! not even the one I was getting before routing stderr.out. I did >> a the -l option, but that should not result in no error messages... >> >> So now what? >> > > Is the tar file incomplete?I figured out I need to do a file count for the directories I am Taring and what is in the tar file.