Re: [BackupPC-users] aborted by signal=PIPE errors.

2008-07-14 23:17:25
Subject: Re: [BackupPC-users] aborted by signal=PIPE errors.
From: Adam Goryachev <mailinglists AT DOT au>
To: backuppc-users AT lists.sourceforge DOT net
Date: Tue, 15 Jul 2008 13:17:16 +1000
Hash: SHA1

Holger Parplies wrote:
> Hi,
> Peter Nankivell wrote on 2008-07-15 09:17:48 +1000 [Re: [BackupPC-users] 
> aborted by signal=PIPE errors.]:
>> [...]
>> If it is all due to ssh and hardware it makes me worry about
>> the resilience of ssh.  Surely its protocol should be able to
>> retry on corrupted data?  I don't know...
> actually, TCP should provide ssh with a reliable data stream. If ssh *sees*
> corrupted data, then either
>   1) the data has been tampered with or
>   2) TCPs CRC failed to identify network data corruption.
> While (2) is conceivable, it should *not* be happening on a regular basis (if
> it is, something else is wrong). I would guess it to be so rare that ssh
> ignores the possibility, since there is no way to distinguish between both
> cases. In the case of tampering, retransmissions would not make much sense
> ("Hey, I noticed that! Be more subtle next time." :-).
>> Another solution maybe to use "rsyncd".  This should avoid
>> using ssh as the transport.  I haven't tried this yet.
> Providing you really have a corrupted TCP data stream, that would mean
> corrupted backups ... or an rsync protocol failure.

I recently experienced a very long battle with this exact problem.

A brand new server was being installed using an NFS root which was
mounted via TCP NFS. I was seeing random crashes usually related to NFS
disk errors and similar. After using wireshark on the NFS server to
'watch' the traffic, I noticed a number of corrupted TCP (NFS) packets
arriving. I concluded it was a network issue, and proceeded to replace
the network card on the NFS client, the cable, and the switch. I was
still seeing the same errors, so I finally gave up and ran a memtest,
which found faulty memory. I replaced the memory and it has been stable
ever since.

Just a suggestion, because again, TCP was not resolving the corrupt
packet issue, the packets were getting through to the NFS layer, causing
other issues since NFS doesn't seem to handle corrupt packets very well.


- --
Adam Goryachev
Website Managers
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net