BackupPC-users

Re: [BackupPC-users] BackupPC fails with aborted by signal=PIPE, Can't write to socket

2017-01-20 09:59:21
Subject: Re: [BackupPC-users] BackupPC fails with aborted by signal=PIPE, Can't write to socket
From: John Spitzer <johned9999 AT comcast DOT net>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Fri, 20 Jan 2017 06:56:43 -0800
This is exactly the kind of information I was hoping to get. I had 
overlooked where these timeout values were configured. I will experiment 
with these settings and get back with my results.

Thank you Stefan for this very helpful information.

Kind Regards,
John S.
On 01/20/2017 12:13 AM, Stefan Peter wrote:
> Am 20.01.2017 um 04:57 schrieb John Spitzer:
>> On 01/19/2017 1:28 PM, Les Mikesell wrote:
>>> On Thu, Jan 19, 2017 at 2:25 PM, John Spitzer <johned9999 AT comcast DOT 
>>> net>
>>> wrote:
>>>
>>> The most likely suspect is that rsync timeout shown in the log snippet
>>> you posted.  But you didn't provide any details about why or how your
>>> rsync had timeouts enabled.
>>>
>> That rsync timeout is being set 'under the hood'.
> No, I don't think so. If you use the rsync method, make sure your
> RsyncClientCmd does not use the --timeout parameter or at least sets a
> reasonably high paramter value.
> ount
> from man rsync:
>   --timeout=TIMEOUT
>       This  option allows you to set a maximum I/O timeout in seconds.
>       If no data is transferred for the specified time then rsync will
>       exit. The default is 0, which means no timeout.
>
> An additional issue I had with this method at some point was that the
> ssh connection was terminated, most probably by one of the two firewalls
> involved. When doing large file transfers, rsync tends to take quite
> some time doing checksums and the like in order to reduce the amount of
> data to be transferred. This results in long times when nothing is
> transferred over the ssh connection which in turn may lead a firewall to
> believe that the connection is dead.
> Setting the ClientAliveCountMax and ClientAliveInterval in sshd_config
> on the client fixed this problem for me. Again, man sshd_config may help
> you with details.
>
>
>
> If you use the rsyncd method, you will have to set the timeout value in
> the rsyncd.conf file on the client. From man rsyncd.conf:
>   timeout
>       This parameter allows you to override the clients choice for I/O
>       timeout for this module. Using this  parameter  you  can  ensure
>       that  rsync  won’t wait on a dead client forever. The timeout is
>       specified in seconds. A value of zero means no  timeout  and  is
>       the  default.  A  good choice for anonymous rsync daemons may be
>       600 (giving a 10 minute timeout).
>
> In one notoriously busy and slow server I had to set this to 3600
> seconds in order to be able to backup DVD images.
>
> With kind regards
>
> Stefan Peter
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users AT lists.sourceforge DOT net
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>


-- 
John Spitzer
johned9999 AT comcast DOT net
H - 503-590-7434
C - 408-234-2988

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/