On Wed, 2 Oct 2013 20:49:22 +0200, Holger Parplies <wb...@parplies.de>
wrote:
> Hi,
>
> backu...@kosowsky.org wrote on 2013-10-02 14:08:16 -0400 [Re:
> [BackupPC-devel] [PATCH] More granular check of pre/post user scripts]:
> > Davide Brini wrote at about 17:57:22 +0200 on Wednesday, October 2,
> > 2013:
> > > [...]
> > >
> > > IIUC, a sequence of commands can *not* be given, since a shell is not
> > > spawned. [...]
> >
> > Not true -- you can use "bash -c"
> > $Conf{DumpPreUserCmd} = ['bin/bash', '-c', 'original command',
> > '/bin/true'];
>
> shouldn't that be ...
>
> $Conf{DumpPreUserCmd} = ['/bin/bash', '-c', 'original command
> || /bin/true'];
Yes, or
$Conf{DumpPreUserCmd} = [ 'bin/bash', '-c', 'original command; /bin/true' ];
since we want to succeed regardless. But anyway, now that you (and Jeffrey)
say that, I remember that the above possibility exists (and it makes sense,
since it's an array that's given as argument to exec).
> > if it didn't truly fail, then why do you care if backuppc thinks it
> > succeeded as a backup.
>
> The point is that you might want to see a log entry to the effect that
> DumpPostUserCmd returned a non-zero exit status - something isn't working
> as expected, even though the backup is succeeding. It's nothing BackupPC
> cares much about, but you, the user/administrator, might be interested.
> And yes, there are other ways to achieve that outside BackupPC. Think of
> it as a warning as opposed to an error.
This is what I meant in my second email, exactly. On the other hand, since
I control that script, and I know its failure is not critical, I can
certainly change it to do
....
dowork
status=$?
notify foo $status
update bar $status
# was: exit $status
exit 0
and still record somewhere (outside backuppc) whether it succeeded or not.
Echoing meaningful messages to stdout/stderr (which BackupPC captures) I
can even have trace of that in the BackupPC logs.
> > I just don't see the need to add the complexity of new
> > variables for the vast majority of use cases.
>
> I tend to agree.
In general, you both make good points. Indeed, since my need can already be
solved using existing facilities (though in a way I had not thought about),
I tend to agree that my patch is not really necessary.
> > 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.
>
> I tend to agree there, too. I don't think there is great general demand
> for an implementation, but I can understand the idea and the personal
> need for one. I'm suggesting a different approach at an implementation if
> one is done (though I realize there is little motivation to change
> anything if this patch works for you, Davide).
Well, an important motivation is the ability to use vanilla packaged or
source versions from upstream, without the need to maintain my private fork.
Thanks again for the useful comments.
--
D.
------------------------------------------------------------------------------
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
BackupPC-devel@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
