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
On 12/09/06, Barry L. Kline blkline@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.err
Will.
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"?
Ralph
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?
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.
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@ipaddrs "cat > backup.tgz"
?
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@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.
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@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.
On 12/09/06, Ralph Angenendt ra+centos@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.
Will.
Will McDonald wrote:
On 12/09/06, Ralph Angenendt ra+centos@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@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.
On 12/09/06, Robert Moskowitz rgm@htt-consult.com wrote:
Will McDonald wrote:
On 12/09/06, Ralph Angenendt ra+centos@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@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.
It appears when you tar to STDOUT it redirects the usual STDOUT messages to STDERR, in addition to the errors, so I guess a separate error log when tar-ing to STDOUT's out.
[wmcdonald@stella /]$ tar cpvzO /proc/ 1> /tmp/proc.stdout 2>/tmp/proc.stderr [wmcdonald@stella /]$ file /tmp/proc.* /tmp/proc.stderr: ASCII text /tmp/proc.stdout: gzip compressed data, from Unix [wmcdonald@stella /]$
Dropping the 'O' option and using - behaves the same...
[wmcdonald@stella /]$ tar cpvz - /proc/ 1> /tmp/proc.stdout 2>/tmp/proc.stderr [wmcdonald@stella /]$ file /tmp/proc.* /tmp/proc.stderr: ASCII text /tmp/proc.stdout: gzip compressed data, from Unix
Will.
Will McDonald wrote:
On 12/09/06, Robert Moskowitz rgm@htt-consult.com wrote:
Will McDonald wrote:
On 12/09/06, Ralph Angenendt ra+centos@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@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.
It appears when you tar to STDOUT it redirects the usual STDOUT messages to STDERR, in addition to the errors, so I guess a separate error log when tar-ing to STDOUT's out.
[wmcdonald@stella /]$ tar cpvzO /proc/ 1> /tmp/proc.stdout 2>/tmp/proc.stderr [wmcdonald@stella /]$ file /tmp/proc.* /tmp/proc.stderr: ASCII text /tmp/proc.stdout: gzip compressed data, from Unix [wmcdonald@stella /]$
ah, will try this tomorrow.
Dropping the 'O' option and using - behaves the same...
Is there an advantage of one over the other? Origin note I found had the '-' and I changed it to 'O'
[wmcdonald@stella /]$ tar cpvz - /proc/ 1> /tmp/proc.stdout 2>/tmp/proc.stderr [wmcdonald@stella /]$ file /tmp/proc.* /tmp/proc.stderr: ASCII text /tmp/proc.stdout: gzip compressed data, from Unix
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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@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?
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@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.
Will McDonald wrote:
On 12/09/06, Barry L. Kline blkline@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.err
Doubt if it would be for brevity sake, rather the ablity to see all that happened!
And forgot about standerr....
Will McDonald wrote:
On 12/09/06, Barry L. Kline blkline@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.err
Wait 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@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?
Robert Moskowitz wrote:
Wait 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@ipaddrs "cat > backup.tgz"
So where is the verbose going to so I see it on the screen? STDERR?
Normal UNIX tools write data to stdout and everything else like error messages, status messages etc to stderr.
tar ... > file.tar
will save your data (the tar file) to the file and the messages will be seen on the terminal. You can redirect them if you want with 2>
tar ... > file.tar 2> tarlog.txt
And still either how do I unlock any locked files left locked by X? And/or just tar them with the lock?
You don't need to backup lock files. They won't make sense if restored anyway. Most tools will create new locks when they start next time. Some tools will complain if there is a lock file already there when they start up.
John.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
-
Barry L. Kline -
John Newbigin -
Les Mikesell -
Ralph Angenendt -
Robert Moskowitz -
Will McDonald