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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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
Hi,
Ralf Gross wrote on 19.01.2007 at 09:32:01 [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.
> [...]
>
> 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.
supposing you don't really need tar 1.16 on the client machine(s), you could
always downgrade to tar 1.14 from sarge (or a previous 1.15 from etch) until
there is an official solution. Note that the current sarge tar package is a
security update. From DSA-1223-1:
> i386 architecture (Intel ia32)
>
> http://security.debian.org/pool/updates/main/t/tar/tar_1.14-2.3_i386.deb
> Size/MD5 checksum: 499560 c764b0894f6c3317a78124177cfed9fe
>
> ia64 architecture (Intel ia64)
>
> http://security.debian.org/pool/updates/main/t/tar/tar_1.14-2.3_ia64.deb
> Size/MD5 checksum: 543432 0dc8b4d66a82d05d7b68f2dbee960791
>
> amd64 architecture (AMD x86_64 (AMD64))
>
> http://security.debian.org/pool/updates/main/t/tar/tar_1.14-2.3_amd64.deb
> Size/MD5 checksum: 503902 98a8169210eb273252a7997c726c4333
>
> sparc architecture (Sun SPARC/UltraSPARC)
>
> http://security.debian.org/pool/updates/main/t/tar/tar_1.14-2.3_sparc.deb
> Size/MD5 checksum: 499698 d260b9f5db00b12414d6136c63e37202
You can either download the relevant file (and preferably verify its
checksum against the one listed on the Debian web site, which should hopefully
correspond to the one I quoted :) and 'sudo dpkg -i' it (perhaps first test
with 'dpkg --no-act -i ...'), or preferably add
deb http://security.debian.org/ sarge/updates main
to your sources.list and
% sudo apt-get update; sudo apt-get install tar=1.14-2.3
to install it. This has the advantage of warning you first, should something
installed on your system depend on a newer version of tar (in a more
readable format than the 'dpkg --no-act ...').
Once downgraded, prevent upgrading to the etch version again with
% echo 'tar hold' | sudo dpkg --set-selections
(which you would later undo with
% echo 'tar install' | sudo dpkg --set-selections
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'.
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").
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 ;-)
- 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.
Regards,
Holger
-
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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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.125&root=tar&view=auto): GNU tar NEWS - User visible changes. Please send GNU tar bug reports to 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.php&p=sourceforge&CID=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
"Vin cius Medina" writes: > I am having this problem with BackupPC: > Running: /usr/bin/ssh -q -n -l USER* HOST* /bin/gtar -c -v -f - -C > /arquivos/ --totals . What happens when you run this: su backuppc /usr/bin/ssh -q -n -l USER* HOST* /bin/gtar -c -f - -C /arquivos/ --totals . | tar -tvf - or even /usr/bin/ssh -q -n -l USER* HOST* /bin/gtar -c -f - -C /arquivos/ --totals . | od -c | more Craig --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
