Re: [BackupPC-devel] [PATCH] More granular check of pre/post user scripts

[<bac...@ko...>]

Davide Brini wrote at about 17:57:22 +0200 on Wednesday, October 2, 2013:
 > On Wed, 02 Oct 2013 11:25:47 -0400, <bac...@ko...> 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 (as per Craig's note a few
 > > weeks back, a sequence of commands can be given so this can be
 > > appended to the end). Seems much cleaner and both simpler to
 > > understand and implement...
 > 
 > 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.

Not true -- you can use "bash -c"
$Conf{DumpPreUserCmd} = ['bin/bash', '-c', 'original command', '/bin/true'];

 > 
 > 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.

If it truly failed as a backup to the extent that there is some issue
with the quality of the backup, why would you want it to keep the data; if it
didn't truly fail, then why do you care if backuppc thinks it
succeeded as a backup.

 > 
 > Note that there may be situations where it *does* makes sense to fail the
 > whole backup instead; I'm just saying that one should be able to tell
 > backuppc what to do, instead of blindly assuming "failure == delete dump"
 > (or "failure == keep backup") for everything.

Well you can do it for command by command using the above methodology.

I'm sure one can think of corner cases that lie between the two modes
of failure, but for the vast majority of the cases, the above is far
simpler. Frankly, I just don't see the need to add the complexity of new
variables for the vast majority of use cases. That doesn't mean your
patch isn't useful to you and maybe some others but I question its
general utility relative to the complexity, especially given that 3.x
is no longer being actively developed for new functionality.

With the simple mod I suggest, then you can think of each command as
either being required or not required to succeed for the backup to
continue and complete.