I stand corrected. I would have replied earlier, but my spam scanner decided your message was spam.
Anyway, grepping through all of my perl code didn't reveal any system() calls. Not surprising since I generally avoid system() like the plague. I usually open my commands using something similar to.. open PS,"/bin/ps -p $pid |" or die "Couldn't spawn ps: $!\n"; open LOCK,">$LOCK" or die "Could not create $LOCK: $!\n"; or unlink $TMPERR or die "Error! Can't unlink $TMPERR: $!\n"; But after thinking about it, what you said makes sense and if it's in the Camel book, who am I to argue? :-) Cheers, Stephen -- Stephen Joyce Systems Administrator P A N I C Physics & Astronomy Department Physics & Astronomy University of North Carolina at Chapel Hill Network Infrastructure voice: (919) 962-7214 and Computing fax: (919) 962-0480 http://www.panic.unc.edu Don't judge a book by its movie. On Sun, 21 Oct 2007, Holger Parplies wrote: > Hi, > > Stephen Joyce wrote on 21.10.2007 at 13:37:52 [Re: [BackupPC-users] Question > about wrapping rsync]: >> On Sun, 21 Oct 2007, Holger Parplies wrote: >>>> So, my script simply stops running after: >>>> system("$rsyncPath @argList $newShare\n") || die "$rsyncPath @argList >>>> $shareName failed!"; >>> >>> Maybe because it should be "and" and not "or"? system returns the exit >>> status of the program, so a 0 return value means success, causing the "die" >>> to take effect. Aside from that, the die message quotes $shareName whereas >>> the command uses $newShare. That may or may not be intended :). >> >> Actually, in perl it's common to use the "do something or die" syntax. > > right, where it makes sense, it is. Where it doesn't, it is not. system() is > one of few examples where it doesn't. I didn't just accidentally point it > out. > >> It does exactly what the syntax says; the first part must succeed (exit with >> 0) or the program will die. > > Actually, Perl functions are in the general habit of returning something > that evaluates to "true" for success. The value 0 is not a good example for > this, because it is *not* "true". system() is simply an exception. See the > Camel Book, page 143, for details. You are thinking of shell programming. > > The "or" operator (or "||", which is "or" with a higher precedence) behaves > like an "or" (that's why it's called "or", believe it or not) with > short-circuit evaluation. If the result is determinable from the first > argument alone, the second is never evaluated. From a "false" value as first > argument, the result of an "or" is not determinable, so the second argument > is evaluated. From a "true" value, the result of the "or" is "true", > regardless of what the other argument would evaluate to. > > This means, if something evaluates to "true" on success, then it makes > sense to use the "foo or die" idiom (or "foo or bar" if you don't want to > die but just need a drink). If something evaluates to "false" on success > (and the system function is one of the rare examples of this), then this > does *not* work. Look at the example in "perldoc -f system". It reads > > system(@args) == 0 > or die "system @args failed: $?" > > which is equivalent to either > > not(system(@args)) or die "..." > > or > > system(@args) and die "..." > > That seems strange at first sight. Note that we're not interested in the > return value of the "and" (or "or") though. We only want the "die" to happen > if and only if system(@args) evaluates to "false". > >> I would suggest modifying it to something like >> system("$rsyncPath @argList $newShare\n") or die "$rsyncPath @argList >> $shareName failed with error: $!\n"; > > Even more wrong! system() does not put the error in $!. See the example > from the Perl documentation above. $? is what you want to look at. And it's > still "and" (or !system() or (system()==0) or ...). > >> But be careful that you're redirecting STDOUT and STDERR to a file >> somewhere on the local host. Otherwise at that point in the script they may >> go nowhere (see below). > > To that I can agree. > >>>> My question is - does BackupPC actively kill the "rsync" after the >>>> backup is finished? I tried catching SIGPIPE and doing the cleanup >>>> then, but that didn't help. >>> >>> Without looking at the code, I would suspect BackupPC to close the socket >>> after transfer is finished (what else should it do? Wait for the remote side >>> to close it?). I would imagine that might generate a SIGHUP (probably only >>> if you've got a controlling tty). SIGPIPE should only be triggered if you >>> try to write to a closed socket. >> >> I'd guess that this is exactly what's happening; BackupPC closes the >> socket. Depending on the script on the remote side it could continue or die >> when it loses it's controlling tty. >> >> I'm not sure there's a way to do what you want without using DumpPreUserCmd >> and DumpPostUserCmd scripts. > > Where's the problem? We've just agreed that BackupPC almost certainly does > nothing more than close the socket. There's nothing that is *forcing* the > script on the remote side to die (as would a SIGKILL), it's just a matter of > handling whatever circumstance is not yet handled correctly. The rest of the > script is apparently working, so why give up now? > > Regards, > Holger > > > -- > > ------------------------------------------------------------------------- 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 BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
