<div class="gmail_quote">On Thu, Jun 9, 2011 at 2:29 PM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And, to provide a bit more info that may make it easier for you to<br>
diagnose issues in the future, Ken, the MythTV exit codes are only<br>
useful when a program shuts down properly. If a MythTV application is<br>
terminated through a signal, you will get a shell-provided exit status.<br>
So, for example, bash provides a value of 128 + n if the process is<br>
terminated with signal n.<br></blockquote><div><br></div><div>Well, this isn't 100% accurate, but for an Ubuntu system it turns out that way anyways somehow. We do normally see the return correctly, but somehow the libc in some versions of Ubuntu seems to hand back a byte-swapped status ONLY on signals, which is absurd, but there it is. I keep meaning to put in some non-intrusive code to deal with it better. It's the return of wait() that's the culprit. On other non-affected systems, that would have logged that it died with signal 6, not as an exit value of 134.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">(Note that the particular value for signals is not guaranteed to be<br>
constant across operating systems/platforms/distros/..., so always check<br>
"man 7 signal" for the proper meaning of a signal.)</blockquote><div><br></div><div>There are a certain set of them that are defined by POSIX and will not vary (including ABORT and SEGV), but yeah. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
</blockquote></div>