On 12/21/18 12:05 PM, CLOSE Dave wrote:
> Yesterday, I wrote:
>
>> I have a script that uses rsync to pull the Fedora repositories
>> nightly. If I run it manually, it works flawlessly. But if it runs
>> via cron, I get an error on all the Fedora 28 repositories. I do not
>> get the error on Fedora 27 or RPMFusion 27 or 28 repositories. The
>> script sets timeout values to 3600 seconds but fails in only a few
>> seconds. (I haven't started to sync F29 repos yet.)
>>
>> The error message is,
>>
>> rsync: safe_read failed to read 1 bytes [Receiver]: Connection
>> reset by peer (104)
>> rsync error: error in rsync protocol data stream (code 12) at
>> io.c(276) [Receiver=3.1.3]
>>
>> The commands in the script are,
>>
>> # cat mirror
>> #!/bin/sh
>> /root/bin/mirror-fedora-27
>> /root/bin/mirror-fedora-28
>> /root/bin/mirror-rpmfusion-27
>> /root/bin/mirror-rpmfusion-28
>
> Just for the heck of it, I changed this script last night to reverse the
> order of the first two subordinate scripts:
>
> # cat mirror
> #!/bin/sh
> /root/bin/mirror-fedora-28
> /root/bin/mirror-fedora-27
> /root/bin/mirror-rpmfusion-27
> /root/bin/mirror-rpmfusion-28
>
> And the problem changed. Now it was the F27 updates which failed with
> the error above. (And, yes, I know F27 is no longer being updated so,
> even if it worked, there shouldn't have been any updates loaded.)
>
> And the F27 subordinate script is,
>
> # cat mirror-fedora-27
> #!/bin/sh
> opt="-aHv --timeout=3600 --contimeout=3600 --exclude=repoview/**"
> opt+=" --usermap=:apache --groupmap=:apache --exclude=0ad-*"
> opt+=" --exclude=/*/armhfp/** --exclude=debug/**"
> opt+=" --exclude=repoview/** --exclude=*.html"
> opt+=" --exclude=/*/SRPMS/** --delete-excluded"
> src="rsync://mirrors.kernel.org/fedora"
> dst="/var/www/html/pub/fedora/linux"
> r="releases"; u="updates"; s="Server"; e="Everything"; w="Workstation"
> doit () {
> mkdir -p $dst/$3
> rsync $opt $src/$2 $dst/$3
> }
> doit "$e x86_64" $r/27/$e/x86_64/os/ $r/27/$e/x86_64/os
> doit "$s x86_64" $r/27/$s/x86_64/os/ $r/27/$s/x86_64/os
> doit "$w x86_64" $r/27/$w/x86_64/os/ $r/27/$w/x86_64/os
> doit "$u x86_64" $u/27/$e/x86_64/ $u/27/$e/x86_64/os
>
> Other scripts are similar with the obvious substitutions.
>
> Note that, even after the failures in the F27 updates last night or the
> F28 updates previously, the RPMFusion updates did not fail.
Ok, so it looks like one of the scripts is leaving you in a bogus
directory so the next script fails. Like I said, environment things can
be subtle.
In scripts, I typically have an explicit "cd /some/base/dir" command
inside a loop so I know each iteration of the loop is executing from a
known base directory and not wherever the last iteration of the loop
left me.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- LOOK OUT!!! BEHIND YOU!!! -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
