[mythtv-users] mythcommflag failures with master

Michael T. Dean mtdean at thirdcontact.com
Thu Jun 9 23:19:05 UTC 2011

On 06/09/2011 06:53 PM, Gavin Hurlbut wrote:
> On Thu, Jun 9, 2011 at 2:29 PM, Michael T. Dean wrote:
>> And, to provide a bit more info that may make it easier for you to
>> diagnose issues in the future, Ken, the MythTV exit codes are only
>> useful when a program shuts down properly.  If a MythTV application is
>> terminated through a signal, you will get a shell-provided exit status.
>> So, for example, bash provides a value of 128 + n if the process is
>> terminated with signal n.
> 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.

Heh, I assumed he had run mythcommflag manually through the shell to see 
its exit status, so bash gave him a 134.  But that Ubuntu weirdness 
would explain how he could see that value in the job queue status.

So, my comments apply when running something from the shell.  Gavin's 
apply to "affected systems" even when the process is run through 
mythbackend or mythjobqueue or mythfrontend or whatever.


More information about the mythtv-users mailing list