Exit codes of gLExec
Both the gLExec tool itself and the executed command can return there own error codes. Since version 0.6.0-1 we've consolidated the error codes of gLExec to a minimal set to allow gLExec users to be able to distinguish between the error codes of gLExec and the error codes of the executed command.
For older versions of gLExec, versions before 0.6.x-y, like 0.5.42-1, the error codes of gLExec are not deterministic and the way of distinguishing between the executed command and gLExec is not support. The 0.5.x versions of gLExec are therefore being phased out soon and advise all site administrators to install 0.6.8-3 or newer to provide the best support for the user community.
The exit code of gLExec will simply be the return value of the command that was executed.
The error code that gLExec* returns:
201 - client error, which includes:
- no proxy is provided
- wrong proxy permissions
- target location is not accessible
- the binary to execute does not exist
- the mapped user has no rigths to execute the binary when GLEXEC_CLIENT_CERT is not set
202 - system error
- glexec.conf is not present or malformed
- lcas or lcmaps initialization failure, can be obtained moving the lcas/lcmaps db files.
203 - authorization error
- user is not whitelisted
- local lcas authorization failure
- user banned by the SCAS server
- lcmaps failure on the scas server
- SCAS server not running
- network cable unplugged on the SCAS server host.
204 - exit code of the called application overlap with the previous ones
- application called by glexec exit with code 201, 202, 203 or 204
126 - Shell returns that the executable can’t be executed:
- This error code is triggered when the given command is unable to be executed. This could be due to execution permissions problems, ACL problem, or other shell related reasons for not executing.
128+n - Child exited due to signal n.
The following sequence will print the output of /bin/ls and echo the shell exit code of the previous command.
bash $: /opt/glite/sbin/glexec /bin/ls; echo $?
This works on most to all shells. We've noticed that SASH (Stand-alone shell) doesn't keep the error code in the $? parameter when the $? is not used on the same line. For SASH compatibility use the following construction:
sash $: /opt/glite/sbin/glexec /bin/ls; echo $?
More information can be found in the Man pages of gLExec.