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

2008-07-15 01:01:19
Subject: Re: [BackupPC-users] aborted by signal=PIPE errors.
From: Peter Nankivell <nanks AT DOT au>
To: backuppc-users AT lists.sourceforge DOT net
Date: Tue, 15 Jul 2008 15:01:03 +1000

Yes.  It is conceivable that something on the motherboard could be
causing a TCP problem if the corruption occurs after the TCP packets
are unpacked.  I'll check the memory on both the client and server tonight.
Although I suspect the client as the server backs up other machines OK.

Thanks, Peter.

On Tuesday 15 July 2008 13:17:16 Adam Goryachev wrote:
> 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.
> Regards,
> Adam

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