Re: [BackupPC-users] tar error 256
Holger writes:
Another possibility could be to write a wrapper around either ssh on the
server or tar on the client to change an exit code of 1 to an exit code of 0,
but that probably has the problem of affecting more serious errors as well
(if it was as simple as patching exit code 1 to 0, I guess there would be a
fix in place already). You could even do this in BackupPC itself, *possibly*
as simple as changing line 213 (in 3.0.0beta3) in Xfer::Tar.pm as in
-if ( !close($t-{pipeTar}) ) {
+if ( !close($t-{pipeTar}) and $? != 256 ) {
but that
a) is *totally* untested,
b) will affect all clients and not only one and
c) will make all failures returning exit code 1 to be regarded as ok
(provided it even works)
- four good reasons not to try it unless you are really desperate :-). With
a wrapper around ssh or tar you can at least limit the effect to one client.
But downgrading tar still seems safest to me.
I hope someone can give you a better solution.
Your solution is fine. I looked at the source for tar 1.16 and it
returns an exit status of 1 only in the case when a file changed
during reading. More specifically:
- the file length changed during reading (eg: more/less bytes
read than the file size returned by stat), or
- the mtime changed while the file was being archived.
d) will of course void your BackupPC warranty ;-)
You are right of course :)
I'll make the change in 2.x and 3.x.
Craig
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] tar error 256
Craig Barratt schrieb: What version of tar are you using? Torsten reported that the newest version has changed the exit status in the case of certain relatively benign warnings that are therefore considerd fatal by BackupPC. Could you also look through the XferLOG file and confirm that it is this same warning that tar is reporting? I still need to fix this issue for 3.x. Is there a workaround for backuppc 2.x or 3.x? I'm seeing more of these errors and it's definitively because of a file that has changed during read. Test with tar 1.16 (debian etch) * changed file /tmp$ /usr/bin/ssh -c blowfish -q -x -n -l root wl000346 env LC_ALL=C /bin/tar -c -vv -f - -C /home/rg/test --totals --newer=2007-01-12 . /tmp/foo.tar.gz ; echo exitstate: $? /bin/tar: Option --after-date: Treating date `2007-01-12' as 2007-01-12 00:00:00 drwxr-xr-x root/root 0 2007-01-19 09:08 ./ -rw-r--r-- root/root 3387392 2007-01-19 09:14 ./TEST--TEST /bin/tar: ./TEST--TEST: file changed as we read it Total bytes written: 3389440 (3.3MiB, 5.1MiB/s) exitstate: 1 * no change /tmp$ /usr/bin/ssh -c blowfish -q -x -n -l root wl000346 env LC_ALL=C /bin/tar -c -vv -f - -C /home/rg/test --totals --newer=2007-01-12 . /tmp/foo.tar.gz ; echo exitstate: $? /bin/tar: Option --after-date: Treating date `2007-01-12' as 2007-01-12 00:00:00 drwxr-xr-x root/root 0 2007-01-19 09:08 ./ -rw-r--r-- root/root 5099520 2007-01-19 09:14 ./TEST--TEST Total bytes written: 5109760 (4.9MiB, 7.8MiB/s) exitstate: 0 Test with tar 1.15.1 (solaris) * changed file [EMAIL PROTECTED]:/tmp$ /usr/bin/ssh -c blowfish -q -x -n -l root bang env LC_ALL=C /usr/local/bin/tar -c -vv -f - -C /export/home/rg/test --totals --newer=2007-01-12 . /tmp/foo.tar.gz ; echo exitstate: $? /usr/local/bin/tar: Treating date `2007-01-12' as 2007-01-12 00:00:00 + 0 nanoseconds drwxr-x--- rg/other 0 2007-01-19 09:21:05 ./ -rw-r- rg/other 0 2007-01-04 14:46:00 ./foo -rw-r- rg/ve 1122304 2007-01-19 09:21:12 ./TEST--TEST /usr/local/bin/tar: ./TEST--TEST: file changed as we read it Total bytes written: 1126400 (1.1MiB, 4.2MiB/s) exitstate: 0 * no change /tmp$ /usr/bin/ssh -c blowfish -q -x -n -l root bang env LC_ALL=C /usr/local/bin/tar -c -vv -f - -C /export/home/rg/test --totals --newer=2007-01-12 . /tmp/foo.tar.gz ; echo exitstate: $? /usr/local/bin/tar: Treating date `2007-01-12' as 2007-01-12 00:00:00 + 0 nanoseconds drwxr-x--- rg/other 0 2007-01-19 09:21:05 ./ -rw-r- rg/other 0 2007-01-04 14:46:00 ./foo -rw-r- rg/ve933888 2007-01-19 09:21:11 ./TEST--TEST Total bytes written: 942080 (920KiB, 3.6MiB/s) exitstate: 0 Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] tar error 256
Holger Parplies schrieb:
Craig Barratt schrieb:
What version of tar are you using? Torsten reported that the
newest version has changed the exit status in the case of
certain relatively benign warnings that are therefore considerd
fatal by BackupPC.
[...]
Is there a workaround for backuppc 2.x or 3.x? I'm seeing more of these
errors
and it's definitively because of a file that has changed during read.
[downgrade debian tar]
when you want to switch to the etch version again).
All instances of 'sudo' are meant to document what requires root priviledges
and what doesn't. You can, of course, do everything as root without 'sudo'.
Luckily the deb was still in my apt cache. I set the packet on hold
now. I thought about this before, but I would like a solution that is
working wth the new tar too. I think it's just a question of time
until Craig will come up with a better solution.
I don't really like that approach, and it might be cumbersome if you are
talking about many client machines, but otherwise it's rather easy to do
and probably safe (and you wrote one machine).
I've just updated/installed 3 debian etch servers - more to come ;)
Another possibility could be to write a wrapper around either ssh on the
server or tar on the client to change an exit code of 1 to an exit code of 0,
but that probably has the problem of affecting more serious errors as well
(if it was as simple as patching exit code 1 to 0, I guess there would be a
fix in place already). You could even do this in BackupPC itself, *possibly*
as simple as changing line 213 (in 3.0.0beta3) in Xfer::Tar.pm as in
-if ( !close($t-{pipeTar}) ) {
+if ( !close($t-{pipeTar}) and $? != 256 ) {
but that
a) is *totally* untested,
b) will affect all clients and not only one and
c) will make all failures returning exit code 1 to be regarded as ok
(provided it even works)
d) will of course void your BackupPC warranty ;-)
Downgrading to tar 1.16 seem to me to be the preffered method at the moment.
- four good reasons not to try it unless you are really desperate :-). With
a wrapper around ssh or tar you can at least limit the effect to one client.
But downgrading tar still seems safest to me.
Yes.
I hope someone can give you a better solution.
I think it's funny that this change was not classified as Incompatible change
in the Changelog...
Ralf
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] tar error 256
- Craig Barratt [EMAIL PROTECTED] wrote: [snip...] What version of tar are you using? Torsten reported that the newest version has changed the exit status in the case of certain relatively benign warnings that are therefore considerd fatal by BackupPC. Both client and server are running GNU tar 1.16-2 from Debian/Sid. Could you also look through the XferLOG file and confirm that it is this same warning that tar is reporting? It is confirmed. It said two files (/var/log/auth.log and /var/log/syslog) were being changed as they were being written...As well as /archive/mp3, which shouldn't be changing, and looks unchanged... --b - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
[BackupPC-users] tar error 256
Running into a problem with my larger machines doing backups. 90% of the time, the backup ends with the following message: backup failed (Tar exited with error 256 () status) I believe I read somewhere that it was due to a file changing during backup, probably in combination with the latency introducted in backup across the network. The reason I went with tar in the first place is that I read that rsync consumes more memory the larger the file list is, and this box has 256MB of RAM. My question at this point is the best approach to fixing this problem. I have been running backuppc since the beginning of the year, so I have at least 2 fulls and a weeks worth of incrementals, so, at least in theory, the number of files being rsynced should not be overly large. So should I convert my problem children to rsync, or should I convert everything over to rsync? Or is there a workaround for tar? Thanks, --b - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] tar error 256
Bradley writes: Running into a problem with my larger machines doing backups. 90% of the time, the backup ends with the following message: backup failed (Tar exited with error 256 () status) I believe I read somewhere that it was due to a file changing during backup, probably in combination with the latency introducted in backup across the network. The reason I went with tar in the first place is that I read that rsync consumes more memory the larger the file list is, and this box has 256MB of RAM. My question at this point is the best approach to fixing this problem. I have been running backuppc since the beginning of the year, so I have at least 2 fulls and a weeks worth of incrementals, so, at least in theory, the number of files being rsynced should not be overly large. So should I convert my problem children to rsync, or should I convert everything over to rsync? Or is there a workaround for tar? What version of tar are you using? Torsten reported that the newest version has changed the exit status in the case of certain relatively benign warnings that are therefore considerd fatal by BackupPC. Could you also look through the XferLOG file and confirm that it is this same warning that tar is reporting? I still need to fix this issue for 3.x. Craig -- Forwarded message -- To: backuppc-users@lists.sourceforge.net From: Torsten Sadowski [EMAIL PROTECTED] Date: Fri, 1 Dec 2006 13:55:15 +0100 Subj: [BackupPC-users] /bin/tar: ./totty: file changed as we read it Hi, the new tar seems to be a bit more nervous than the old one. One Problem could be solved with LANG=C but another point are probably changes in the backed up filesystem. Is there a possibility to ignore this error? Cheers, Torsten /bin/tar: ./totty: file changed as we read it [ skipped 1 lines ] Tar exited with error 256 () status [ skipped 46 lines ] tarExtract: Done: 0 errors, 1557378 filesExist, 63760417431 sizeExist, 45188423124 sizeExistComp, 1615232 filesTotal, 63767351947 sizeTotal Got fatal error during xfer (Tar exited with error 256 () status) Backup aborted (Tar exited with error 256 () status) -- Forwarded message -- To: backuppc-users@lists.sourceforge.net From: Torsten Sadowski [EMAIL PROTECTED] Date: Tue, 5 Dec 2006 10:35:51 +0100 Subj: Re: [BackupPC-users] /bin/tar: ./totty: file changed as we read it I found the reason and a (for now) quick solution. The Reason first (from: http://cvs.savannah.gnu.org/viewcvs/tar/NEWS?rev=1.125root=tarview=auto): GNU tar NEWS - User visible changes. Please send GNU tar bug reports to bug-tar@gnu.org version 1.16 - Sergey Poznyakoff, 2006-10-21 * After creating an archive, tar exits with code 1 if some files were changed while being read. Previous versions exited with code 2 (fatal error), and only if some files were truncated while being archived. The quick solution was to download tar-1.15.1, build and use it. Does 3.0.0 work with tar 1.16? Torsten Am Freitag, 1. Dezember 2006 13:55 schrieb Torsten Sadowski: Hi, the new tar seems to be a bit more nervous than the old one. One Problem could be solved with LANG=C but another point are probably changes in the backed up filesystem. Is there a possibility to ignore this error? Cheers, Torsten /bin/tar: ./totty: file changed as we read it [ skipped 1 lines ] Tar exited with error 256 () status [ skipped 46 lines ] tarExtract: Done: 0 errors, 1557378 filesExist, 63760417431 sizeExist, 45188423124 sizeExistComp, 1615232 filesTotal, 63767351947 sizeTotal Got fatal error during xfer (Tar exited with error 256 () status) Backup aborted (Tar exited with error 256 () status) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] tar error 256
Craig Barratt schrieb: Bradley writes: Running into a problem with my larger machines doing backups. 90% of the time, the backup ends with the following message: backup failed (Tar exited with error 256 () status) I believe I read somewhere that it was due to a file changing during backup, probably in combination with the latency introducted in backup across the network. The reason I went with tar in the first place is that I read that rsync consumes more memory the larger the file list is, and this box has 256MB of RAM. My question at this point is the best approach to fixing this problem. I have been running backuppc since the beginning of the year, so I have at least 2 fulls and a weeks worth of incrementals, so, at least in theory, the number of files being rsynced should not be overly large. So should I convert my problem children to rsync, or should I convert everything over to rsync? Or is there a workaround for tar? What version of tar are you using? Torsten reported that the newest version has changed the exit status in the case of certain relatively benign warnings that are therefore considerd fatal by BackupPC. Could you also look through the XferLOG file and confirm that it is this same warning that tar is reporting? I still need to fix this issue for 3.x. I'm getting the same error from one client since last week. It's an debian etch server that was updates just before the problem started. tar version 1.16, no problems with the old 1.15. Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
