On 14 Feb 2001, Mike Crowl <[EMAIL PROTECTED]> wrote:
> Hello all, 
> 
> About three months ago I deployed rsync to replace rdist on one of
> our Sun 450s.  It has worked so well that we would like to deploy it
> to replace rdist in the rest of our environment.  This will involve
> setting up scheduled jobs on a dozen or so large application servers
> to grab apps from the repository.

I'm glad to hear that.

> Right now I have the output from the cron job going to an email
> command -- which ends up going to me.  I'd like to find a way to
> either track errors by return code, or via some centralized logging.
> Has anyone done this in a way that worked well for them?  Also, if I
> missed a section on return codes somewhere in the documentation
> could someone point me in the right direction?  Thanks in advance,

I'm fairly sure rsync will comply with the Unix convention of
returning false (non-zero) for failures.  The specific return values
should be one of these:

#define RERR_SYNTAX     1       /* syntax or usage error */
#define RERR_PROTOCOL   2       /* protocol incompatibility */
#define RERR_FILESELECT 3       /* errors selecting input/output files, dirs */
#define RERR_UNSUPPORTED 4       /* requested action not supported */

#define RERR_SOCKETIO   10      /* error in socket IO */
#define RERR_FILEIO     11      /* error in file IO */
#define RERR_STREAMIO   12      /* error in rsync protocol data stream */
#define RERR_MESSAGEIO  13      /* errors with program diagnostics */
#define RERR_IPC        14      /* error in IPC code */

#define RERR_SIGNAL     20      /* status returned when sent SIGUSR1, SIGINT */
#define RERR_WAITCHILD  21      /* some error returned by waitpid() */
#define RERR_MALLOC     22      /* error allocating core memory buffers */

#define RERR_TIMEOUT    30      /* timeout in data send/receive */

and a quick grep through the source shows them used quite
consistently.  Please file a bug if there is any situation in which
the return code is not as it ought to be.

Unless tridge objects to further manual-bloat, I will put this into
the manpage for the next release.

For centralized logging, I'd suggest that you look at the log file and
syslog options on the server, and at redirecting stderr/stdout on the
client.  If this is not sufficient, please think on the list about
what would work better for you.

Cheers,
-- 
Martin Pool, Human Resource
Linuxcare. Inc.   +61 2 6262 8990
[EMAIL PROTECTED], http://linuxcare.com.au/
Linuxcare.  Putting Open Source to work.

PGP signature

Reply via email to