> As many know, I use rsync in DumpPreUserCmd to run my shadowmountrsync
> routine on the remote client. This routine has many legitimate reasons
> for not returning success.
> However, the backuppc log often shows on failure:
> 2009-11-24 11:00:04 DumpPreUserCmd returned error status 512... exiting
> I don't understand the 512 status since the rsync man pages lists
> return codes as 0-35. So what does 512 mean?
It's 256 * exitStatus, so the exit status is 2. The lower 8 bits are
the signal number, if any, that killed the process.
$? The status returned by the last pipe close, backtick ("``")
command, successful call to wait() or waitpid(), or from the
system() operator. This is just the 16-bit status word
returned by the traditional Unix wait() system call (or else is
made up to look like it). Thus, the exit value of the
subprocess is really ("$? >> 8"), and "$? & 127" gives which
signal, if any, the process died from, and "$? & 128" reports
whether there was a core dump.
> The only challenge is that commands like DumpPreUserCmd are executed
directly without a shell which means I have to either wrap it in a
> script or in some "bash -c" ugliness.
> Which brings to mind a suggestion...
> Why not execute these commands in a shell.
> They are not run that frequently (once per day per host) so the
> overhead of launching a shell would be low while the benefit would be
> high in terms of flexibility.
It's not the overhead - the goal is to avoid potential security
issues with shells (which come from all the flexibility it offers).
While a shell can certainly be used securely (including careful
argument checking, using absolute paths for executables, using -b
etc), one of several risks include having someone sneak in arguments
that include meta characters (eg "; /bin/rm -rf /").