We are using rsync in ansible playbooks to sync content from a central location to a bunch of machines located in branch offices with limited network bandwidth. To prevent rsync from eating up the whole bandwith during office hours, but allow synching with maximum speed during the night, we start rsync twice a day with different "bwlimits". We also tell rsync to end shortly before office hours begin/end with parameter "--stop-at".
When the time set by --stop-at has passed, rsync end and uses "RERR_TIMEOUT" (30) as return code. This will unfortunately also end our ansible script with an error.
We could, of course, ignore error RERR_TIMEOUT, but since this error code is also returned when a real timeout occurs, we would miss real issues with the network.
Currently the only differentiation between a real timeout and a timeout reached because of --stop-at is the message "stopping at requested limit" in rsyn's output. Of course we could check rsync's output with ansible, but it would be easier if rsync would return with a different exit code.
So what i am asking you is to consider, when hitting the --stop-at limit, to either return with returncode "OK" (0) or introduce a new return code exclusively returned in such a case, so we could safely catch and ignore such errors.
Thanks in advance!
We are using rsync in ansible playbooks to sync content from a central location to a bunch of machines located in branch offices with limited network bandwidth. To prevent rsync from eating up the whole bandwith during office hours, but allow synching with maximum speed during the night, we start rsync twice a day with different "bwlimits". We also tell rsync to end shortly before office hours begin/end with parameter "--stop-at".
When the time set by --stop-at has passed, rsync end and uses "RERR_TIMEOUT" (30) as return code. This will unfortunately also end our ansible script with an error.
We could, of course, ignore error RERR_TIMEOUT, but since this error code is also returned when a real timeout occurs, we would miss real issues with the network.
Currently the only differentiation between a real timeout and a timeout reached because of --stop-at is the message "stopping at requested limit" in rsyn's output. Of course we could check rsync's output with ansible, but it would be easier if rsync would return with a different exit code.
So what i am asking you is to consider, when hitting the --stop-at limit, to either return with returncode "OK" (0) or introduce a new return code exclusively returned in such a case, so we could safely catch and ignore such errors.
Thanks in advance!