John Rouillard wrote:
> 2007-10-25 10:54:00 Aborting backup up after signal PIPE
> 2007-10-25 10:54:01 Got fatal error during xfer (aborted by signal=PIPE)
This means the problem is on the other end of the link - or at least
that the ssh driving it exited.
> lastlog got digests fdb1c560d9ba822ab4ffa635d4b5f67f vs
> fdb1c560d9ba822ab4ffa635d4b5f67f
> create 400 0/0 65700 lastlog
> Can't write 33932 bytes to socket
> Sending csums, cnt = 16, phase = 1
> Read EOF: Connection reset by peer
The process on the remote side is gone at this point.
> If I am reading this right, the last file handled before the signal is
> /var/log/lastlog which is << 2GB (65K approx). When the signal occurs,
> I guess /var/log/ldap is the file in progress.
>
> The ldap file is 22GB in size:
>
> [EMAIL PROTECTED] log]$ ls -l ldap
> -rw------- 1 root root 22978928497 Oct 25 18:46 ldap
>
> Could the size be the issue?
Yes, it sounds very likely that whatever is sending the file on the
remote side can't handle files larger than 2 gigs.
> I have:
>
> $Conf{ClientTimeout} = 72000;
>
> which is 20 hours and the sigpipe is occurring before then.
You'd see sigalarm instead of sigpipe if you had a timeout.
> Also is there a way to tail the xfer logs in realtime while the daemon
> is controling the backup? So I don't have to wait for the backup to
> finish?
You aren't going to see a problem in the log file - the other end is
crashing.
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
