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
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
