[mythtv-users] Mythfrontend lockup

Allen Edwards allen.p.edwards at gmail.com
Tue Oct 8 15:48:57 UTC 2019


On Tue, Oct 8, 2019 at 2:00 AM Stephen Worthington <stephen_agent at jsw.gen.nz>
wrote:

> On Mon, 7 Oct 2019 20:48:29 -0700, you wrote:
>
> >When we left this problem last I was instructed to do my CTRL-ALT-BS to
> >reset the gui and record the time then look at the mythfrontend.log.
> >
> >My wife called my downstairs, I noted the time as 20:30, did the
> >CTRL-ALT-BS. Then about 2 minutes later Myth came back up.
> >
> >Here are three lines out of the log. The first is well before the event
> and
> >I just include it to show that the next line was in fact all that was
> >printed immediately before the event. The last line is the first in a
> >series of Setup records.
> >
> >Oct  7 19:48:33 NewMyth mythfrontend.real: mythfrontend[1643]: I
> >CoreContext mythrender_vdpau.cpp:615 (CheckOutputSurfaces) VDPAU: Added 2
> >output surfaces (total 4, max 4)
> >Oct  7 20:27:18 NewMyth mythfrontend.real: mythfrontend[1643]: E Decoder
> >mythplayer.cpp:3504 (DecoderGetFrame) Player(1q): Decoder timed out
> waiting
> >for free video buffers.
> >Oct  7 20:32:30 NewMyth mythfrontend.real: mythfrontend[6495]: I
> >thread_unknown signalhandling.cpp:194 (SetHandlerPrivate) Setup Interrupt
> >handler.
> >
> >Also, from my desktop upstairs I could see that the backend kept running
> >and mythweb was fine. Myth screen shot did not respond.
> >
> >I would like help on what might be causing this and what I might do to
> >eliminate the 2 minute wait between CTRL-ALT-BS and system restart. Under
> >Mythbuntu, there was no delay.
> >
> >Thank you.
> >
> >Allen
>
> When mythfrontend is not locked up, how long does restarting X with
> Ctrl-Alt-Backspace take if you try manually shutting down mythfrontend
> before you do it?

If it takes much longer when mythfrontend is
> running, then the problem will likely be the bug that mythfrontend
> (and all MythTV GUI programs) has, where it only partially shuts down
> when given a SIGTERM (kill or kill -15) request.  A second SIGTERM is
> needed to get it to shut down fully, and the shutdown of X may be
> waiting for mythfrontend to finish shutting down.  This shutdown bug
> is a fairly longstanding now, but if I remember correctly, you used to
> be using a quite old version of MythTV and it may not have had that
> bug.
>
> I have now written a script to kill mythfrontend properly.  It is
> available to be downloaded from my web server:
>
> http://www.jsw.gen.nz/mythtv/killm
>
> I would suggest putting it in /usr/local/bin and setting it up to be
> allowed to be run from any user (so that the MythTV users can run it):
>
> sudo su
> cd /usr/local/bin
> wget http://www.jsw.gen.nz/mythtv/killm
> chown root:root killm
> chmod u=rwx,og=rx killm
> exit
>
> The script first optionally kills the /usr/bin/mythfrontend script
> that runs and automatically restarts the real mythfrontend program
> (/usr/bin/mythfrontend.real).  Then it does two kill -15 commands on
> mythfrontend.real, and finally checks to see if mythfrontend.real has
> actually shut down and if not, does a kill -9 on it.  It should take
> less than 2 seconds to kill mythfrontend in the worst case, and in the
> best case should take just over 0.1 s.
>
> If you put any parameter text on the command line after the "killm"
> command, such as "killm x", that tells killm to first kill the
> /usr/bin/mythfrontend script so that /usr/bin/mythfrontend.real will
> not be restarted.  If you want that done always, see the comment in
> the script telling you how to set that up.  I use killm without that
> option when I have mythfrontend lock up playing one of my video files
> (I have several that trigger a mythfrontend lockup bug).  I have yet
> to have killm fail to kill mythfrontend, but my mythfrontend lockups
> may not be the same as yours.
>
> I would suggest that the next time you have your mythfrontend problem,
> if possible you ssh into the MythTV box and run "killm" and see if
> mythfrontend.real will die and be restarted.  If it does, then you
> could look at making it possible to run killm from a button on your
> remote control.  If you can not use ssh to get to a command prompt,
> try using Ctrl-Alt-F1 on the MythTV box and login from that console to
> do the killm command.  You need to run killm from either the same user
> as mythfrontend is run from, or from root, or using sudo.  Once you
> have run killm, swap back to the GUI screen using Ctrl-Alt-F7.
>
>
CTRL-ALT-BS took 30 seconds to restart mythfrontend when I just tested it.

In a previous thread I had tried issuing kill twice followed by kill -9
specifically
top (find PID = 1555)
sudo kill 1555
top (still running)
sudo kill 1555
top (still running)
sudo kill -9 1555
ps aux | grep mythfrontend (still running)
sudo killall  mythfrontend.re
ps aux | grep mythfrontend (still running)

mythfrontend did not stop. It presented a message saying do you really want
to kill mythfrontend and just hung waiting for me to press YES which I
could not do because there was no cursor.

The conclusion then was that something else was going on and I should try
the CTRL-ALT-BS next time the system hung, which just happened. I was to
wait to see if myth would eventually come back, and note the time, and see
what the log said around that time. That is what this email is reporting.

You may recall that one change I made was
#DefaultTimeoutStopSec=90s
DefaultTimeoutStopSec=4s

The idea being to reduce the delay. This was recommended in an article I
referenced at the time. Apparently there is still delay somewhere else.

I will note there was some concern that shortening the timeout might not be
a good idea but this computer only runs myth and never hangs except with
myth and as the idea is to shutdown myth quickly, I see no issue.

I will say that waiting 2 minutes is acceptable although not desirable. It
is better than having the thing never shutdown and doing a hard shutdown of
the entire machine which might actually cause disk corruption. Now
mythbackend continues to run and we do not have gaps in what is being
recorded.

So I am reporting what I saw as was agreed to last time. I welcome ideas to
make it more responsive but this is definitely progress.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191008/98a56099/attachment.htm>


More information about the mythtv-users mailing list