On Thu, 2018-01-11 at 08:59 +0100, Ulrich Windl wrote:
> Hi!
>
> Will those exit code be compatible with <sysexits.h>, i.e. will it be
> a superset or a subset of it? If not, it would be the right time.
Yes! It will be a superset. From the new source code:
/*
* Exit statuses
*
* We want well-specified (i.e. OS-invariant) exit status codes for our
daemons
* and applications so they can be relied on by callers. (Function
return codes
* and errno's do not make good exit statuses.)
*
* The only hard rule is that exit statuses must be between 0 and 255;
all else
* is convention. Universally, 0 is success, and 1 is generic error
(excluding
* OSes we don't support -- for example, OpenVMS considers 1 success!).
*
* For init scripts, the LSB gives meaning to 0-7, and sets aside 150-
199 for
* application use. OCF adds 8-9 and 189-199.
*
* sysexits.h was an attempt to give additional meanings, but never
really
* caught on. It uses 0 and 64-78.
*
* Bash reserves 2 ("incorrect builtin usage") and 126-255 (126 is
"command
* found but not executable", 127 is "command not found", 128 + n is
* "interrupted by signal n").
*
* tldp.org recommends 64-113 for application use.
*
* We try to overlap with the above conventions when practical.
*/
We are using 0-1 as success and generic error, 2-7 overlapping with
LSB+OCF, 64-78 overlapping with sysexits.h, 100-109 (possibly more
later) for custom errors, and 124 overlapping with timeout(1).
>
> Regards,
> Ulrich
>
>
> > > > Ken Gaillot <kgail...@redhat.com> schrieb am 10.01.2018 um
> > > > 23:22 in Nachricht
>
> <1515622941.4815.21.ca...@redhat.com>:
> > Every time you run a command on the command line or in a script, it
> > returns an exit status. These are most useful in scripts to check
> > for
> > errors.
> >
> > Currently, Pacemaker daemons and command-line tools return an
> > unreliable mishmash of exit status codes, sometimes including
> > negative
> > numbers (which get bitwise-remapped to the 0-255 range) and/or C
> > library errno codes (which can vary across OSes).
> >
> > The only thing scripts could rely on was 0 means success and
> > nonzero
> > means error.
> >
> > Beginning with Pacemaker 2.0.0, everything will return a well-
> > defined
> > set of reliable exit status codes. These codes can be viewed using
> > the
> > existing crm_error tool using the --exit parameter. For example:
> >
> > crm_error --exit --list
> >
> > will list all possible exit statuses, and
> >
> > crm_error --exit 124
> >
> > will show a textual description of what exit status 124 means.
> >
> > This will mainly be of interest to users who script Pacemaker
> > commands
> > and check the return value. If your scripts rely on the current
> > exit
> > codes, you may need to update your scripts for 2.0.0.
> > --
> > Ken Gaillot <kgail...@redhat.com>
> >
> > _______________________________________________
> > Users mailing list: Users@clusterlabs.org
> > http://lists.clusterlabs.org/mailman/listinfo/users
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc
> > h.pdf
> > Bugs: http://bugs.clusterlabs.org
>
>
> _______________________________________________
> Users mailing list: Users@clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.
> pdf
> Bugs: http://bugs.clusterlabs.org
--
Ken Gaillot <kgail...@redhat.com>
_______________________________________________
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
