Hi,
Davide Brini wrote on 2013-10-02 17:57:22 +0200 [Re: [BackupPC-devel] [PATCH]
More granular check of pre/post user scripts]:
> On Wed, 02 Oct 2013 11:25:47 -0400, <[email protected]> wrote:
>
> > Given that the patch affects several files, a simpler way to
> > accomplish the same (particularly so long as the patch is not formally
> > merged) is to just add something like /bin/true to the end of each
> > command that you want to always succeed [...]
I had been thinking along the same line when I first read the mail on the
users list. My reasoning was, that you almost always have a script, since it
is not that easy to pass a sequence of commands (we've learnt by now that it
seems to be rather easy, if you know the trick), and that in your script you
have full control over the return code passed back.
In that line of thought, the issue remains that executing the script may fail
altogether for some reason, which might not affect the integrity of the backup
at all. Still, some things are "expected to work" - it might be possible to
backup a host even if ping fails, yet it is not attempted (for good reasons)
- so we could likewise define that a hook must succeed for the backup to be
successful (at least if the exit codes are to be checked, which is, after all,
optional).
You could always put a wrapper (C or shell or Perl or whatever) around your
command that does something like
system @ARGV; exit 0;
(Perl example, because handling argument integrity is trivial) or even do
that inline with a Perl hook, if I'm not mistaken.
> IIUC, a sequence of commands can *not* be given, since a shell is not
> spawned. If one wants multiple commands, a script file containing all of
> them has to be created, and then backuppc told to run that file.
Craig recently explained that apparently an array reference can be assigned to
a hook variable, which allows you exact control over argument splitting. Once
you can pass an arbitrary string as *one* argument to 'sh -c', you *can* give
a sequence of commands.
> And anyway, one may want to know and be notified if a script fails.
>
> For instance, I have a post-dump script that sends an email and updates an
> entry in a database; if that fails, I want it to really fail-fail (not
> pretend that it worked because I put "|| /bin/true" at the end), but at the
> same time I'd like backuppc to keep the backup, since the data that was
> transferred is good and in my case it's pointless to throw it away only
> because the post processing script failed.
I would consider your point valid, although you are really only abusing
BackupPC as a logging utility. From BackupPC's perspective there is no
relevant distinction beyond "backup valid or invalid" (i.e. there is no
"well, sort of valid, except that a command failed"), but it would certainly
aid debugging configuration issues if you can easily see whether your script
was executed and whether it completed successfully.
Just the same, I believe that there will be situations where *your script*
would need to determine whether a failure is fatal or not, and not your static
configuration. Imagine, for instance, your post-dump script doing some sort of
verification (failure would be fatal) and then sending an e-mail (failure
should not affect the backup). Or, if that is easier, a *pre*-dump script
doing some necessary setup for the backup to be possible and then some
notification.
So, rather than adding configuration options, I'd suggest defining an exit
code (or range of exit codes) meaning "BackupPC, please log an error but keep
the backup". If this cannot be done in a way unlikely to break existing
setups, it could always be enabled by $Conf{UserCmdCheckStatus} = 2 (or even
'enhanced') ...
Or, another possibility would be to define UserCmdCheckStatus with "levels"
instead of as boolean:
0 - don't check exit status of commands
1 - check exit status of commands
2 - check exit status of Pre* commands only
3 - check exit status tri-state as described above (no error, fatal,
non-fatal)
I'm guessing that Pre* commands tend to set things up (failure would be
fatal), while Post* commands are run after the backup and tend to be
informational or cleanup-type mostly (failure would be non-fatal), so case
'2' might be a short-cut useful to some people. Well, just a suggestion.
Regards,
Holger
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
BackupPC-devel mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
