Some people that have tried to use my mirroring script in the past noticed that if the first rsync call in the script failed (rsync server busy, unavailable, or unreachable) the script would just hang, which kept people from being able to run it from cron; well that's now been fixed. Updated versions are posted: http://luigiwalser.homeip.net:8080/~david/rpmsync.pl - new version with command-line option support (in case you didn't hear) http://luigiwalser.homeip.net:8080/~david/cooksync.pl - old version of the script with just the bug fixed
You can see more chatter about this below. >From this point on, *please* let me know if you have any more problems with my >script. Suggestions and feature requests are also welcome. David Walser wrote: > David Walser wrote: >> Austin wrote: >>> >>> On 2003.05.28 20:12, David Walser wrote: >>>> > I use David's script. Works great! >>>> Glad to hear it. >>> >>> David, >>> I use your script daily (on the command line) and it works great. >>> One problem I'm worried about though... >>> I want to switch it to a cron job, but I noticed that it just hangs on rsync >>> errors. >>> Like a "too many connections" error, or something similar. >> >> I noticed that, and the perl code says basically, open an rsync process, the stdout >> for which will become a filehandle, and if rsync exits with an error, die (the >> script should exit). > > Ok, I have figured out what the problem is, I was misunderstanding the Perl. The > code actually is saying if rsync fails to even be launched at all (probably if it's > not in your path or you don't have execution rights), exit. The return code is > actually the PID of the forked process. > > So I know the problem, I am trying to find the solution now. I need to get the exit > status of the command, I don't care about its PID. Ok, so it's close() that returns false if the program you opened returns with a non-zero exit status, not open(). I also had an infinite loop to contend with. It's now fixed. >> If you figure anything more out about this, let me know. One thing I don't >> remember is what happened the one time the first rsync (line 58) worked, but it >> didn't get the too many connection error until the next one. Usually if it gets it >> at all it's on the first one, because between the rest it usually reconnects fast >> enough to get the spot it was using. > > I still haven't seen this again (first rsync call in the script works but a later > one fails), so if anybody sees this, please let me know what happens. > >>> Austin
