> -----Original Message-----
> From: Nathan Scott [mailto:nathans@xxxxxxxxxx]
> Sent: Monday, July 11, 2016 11:14 AM
> To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> Cc: PCP <pcp@xxxxxxxxxxx>
> Subject: Exit status from PMDA Install/Remove scripts
>
> Hi Ken, all,
>
> Marko noticed an interesting phenomenon, which is that failures within PMDA
> Install scripts are not always being propogated out to the shell.
>
> From a bit of digging into it, I think the problem scenario is a PMDA which
> calls "exit 1" in the Install script itself (i.e. not pmdaproc.sh - auditing
> pmdaproc.sh, everything looks OK wrt trap handling and its __sts use).
>
> But this may be causing the problem - because the pmdaproc.sh is registering
> its trap handler(s), and using __sts at the exit code, if an Install script
> attempts to directly "exit 1" then the 1 code will end up dropped on the floor
> (because pmdaproc.sh trap handler is called, and it uses __sts).
>
> Hmm, how to fix this? We could propagate use of __sts up into the Install
> scripts too. Should we make this a non-double-underscore variable, if we go
> that route?
>
> Or we could introduce trap handling into the top level scripts, and try to
> make
> them play nice with the conflicting trap calls in pmdaproc.sh.
>
> Or something else. Any thoughts / preferences?
I'd vote for Install scripts then need a non-zero exit status to be told about
the pmdarproc.sh trap handler protocol.
You could rename $__sts to $status if you wish, I donât really have an opinion
on this part of it.
Indirectly, this raises the point that there is no really adequate
documentation for the pmdaproc.sh environment that PMDA Install and Remove
scripts are assumed to run in ... pmda(3) has some brief references but I'm
pretty sure this is incomplete. The change for the trap / exit status
propagation might be a good trigger to flush all of the pmdarproc.sh magic
shell variables out into a (new?) man page?
|