[mythtv-users] Frontend locking up and unable to kill it.

Allen Edwards allen.p.edwards at gmail.com
Thu Jul 11 19:01:51 UTC 2019

On Thu, Jul 11, 2019 at 11:10 AM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> On Thu, 11 Jul 2019 10:05:30 -0700, you wrote:
> >On Thu, Jul 4, 2019 at 9:27 AM Stephen Worthington <
> stephen_agent at jsw.gen.nz>
> >wrote:
> >
> >> On Thu, 4 Jul 2019 08:01:48 -0700, you wrote:
> >>
> >> >> Here is what I did:
> >> >top (to find the PID)
> >> >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)
> >> >I believe it was at this point I went downstairs and found the popup
> >> asking
> >> >if I really wanted to kill the program but with no cursor I was unable
> to
> >> >randomly land on the "Yes" area and it did not respond to a "Y" from
> the
> >> >keyboard. The UI was still interactive and I did a right click on the
> >> >mythfrontend tack on the taskbar and said close. The computer was still
> >> >acting normally at this time except no cursor. I then went back
> upstairs
> >> to
> >> >my remote session.
> >> >sudo shutdown now -r
> >> >Then I went downstairs to the computer and pressed the power button,
> which
> >> >normally does a graceful shutdown. Nothing happened so then I held the
> >> >power button down and the computer turned off.
> >> >
> >> >So as you can see, I did kill PID twice.
> >>
> >> OK, so it is not the double kill problem.
> >>
> >> If you need to find the cursor, you can do Ctrl-Alt-T to open a
> >> terminal window and the cursor will show up when it is over that
> >> window.  So you move the window until it is lined up above the thing
> >> you want to click, and then move the cursor straight down off that
> >> window until you think you are in the right place and click.  With
> >> only one degree of freedom, it usually does not take too many tries to
> >> hit the right location.
> >>
> >> Another thing worth trying is to shut down and restart X - if
> >> mythfrontend is locked up waiting for something in X, that should
> >> unlock it.  If you are running lightdm as the display manager, then
> >> you can do that with:
> >>
> >> sudo systemctl restart lightdm
> >>
> >> I do not know if that works with gdm, as I have had to switch to
> >> lightdm on my 18.04 systems in order to get around a gdm problem that
> >> makes x11vnc not work.  It is easy to switch from gdm to lightdm -
> >> just install the lightdm package and reboot.
> >>
> >> It is also a good idea to have a terminal window open in the
> >> background anyway, as with some of the mythfrontend problems, it does
> >> a broadcast crash message (usually an "Assert failed" message) that
> >> gets displayed on all open terminals.
> >>
> >> >I was under the impression that Ubuntu 18.04 would break my LIRC code
> and
> >> >become another project to get the system working again. I ran Mythbuntu
> >> >8.04 until just this year and never had the problems I have had with
> the
> >> >latest install. I thought I had it all fixed but then these two lock
> ups
> >> >happened. Very frustrating.
> >>
> >> Yes, the latest mythfrontend does have a couple of ways of crashing.
> >> But I have not seen it lock up as you are getting.  It also has lots
> >> of nice new things too, and more coming.
> >>
> >> It was the change to kernel drivers and devinput in 14.04? 16.04? that
> >> really broke LIRC setups, but you will have already met that.  So yes,
> >> the LIRC code as installed by the 18.04 package is badly broken, but
> >> you just need to run this script from my web server to fix that:
> >>
> >> http://www.jsw.gen.nz/mythtv/lirc-ubuntu-18.04-install.sh
> >>
> >> I spent a fair few hours working out how to fix LIRC, but now that I
> >> have, it works properly as normal and you should not need much effort
> >> to get it going.  You just need to run the lirc-setup program and
> >> adjust a couple of names in your LIRC config files and it should all
> >> work, if you have a remote such as an MCE or Hauppauge that uses the
> >> devinput driver.
> >>
> >> I do not think you have said what version of MythTV you are running -
> >> is it v30+fixes?
> >>
> >> >Allen
> >> _______________________________________________
> >>
> >
> >MythTV froze again this morning and I will try to clarify the behavior and
> >then ask for some specific help.
> >
> >As suggested I had left a terminal window open and there were no messages
> >but the cursor was working. I tried closing myth using the close click
> >selection on the dropdown in the GUI. At that point I got the dialog about
> >do I really want to close the non responsive program. I moved the terminal
> >over as suggested and was able to use the mouse to close Myth.  I
> restarted
> >it without problems.  My wife started the show clicking on resume from
> >bookmark and it went to the same point in the program and froze again.
> This
> >time I tried the CTRL-ALT-BS and everything on the GUI closed down but
> >nothing restarted as it normally does. Upstairs to open a remote session
> >and did a shdo shutdown now -r.  About 5 minutes later the computer
> finally
> >restarted and things worked fine.  We even played through the scene that
> >froze without incident. It is possible that the CTRL-ALT-BS would have
> >worked if I had waited 5 minutes but I did not.
> >
> >I am going to assume that the GUI is hanging up and causing the 5 minute
> >delay on shutdown.  I am also going to assume that is why CTRL-ALT-BS did
> >not work. An acceptable solution for my use of Myth would be to have
> >CTRL-ALT-BS close a frozen myth without a 5 minute delay. When I was
> >running Mythbuntu 8.04 we occasionally had myth freeze and used
> >to resume and that was fine. Can anyone tell me how to make Myth close
> >without hanging the system for 5 minutes?
> >
> >PS.  I did fsck as suggested a few days ago and there were no errors.
> >
> >
> >Allen
> There is no need to go upstairs to use a remote session.  If you do
> Ctrl-Alt-F1 you should get a text mode screen running a terminal
> session where you can login and kill things or restart X.
> I am surprised that Ctrl-Alt-BS works.  When I last tried it, probably
> Ubuntu 12, it was disabled.  I think it is possible to enable it, but
> my recollection from back then is that the reason it is disabled is
> that it was not likely to work as well as it used to in earlier
> versions due to changes in the way all the GUI setup works.  My
> experience is that when I have had to restart X using "systemctl
> restart lightdm", it restarts rapidly even if there is a frozen
> program.  But it is a while since I last had to do it - Ubuntu 16.04
> probably.  I am suspecting that your problem with Ctrl-Alt-BS may not
> be related to having a frozen mythfrontend.  You should probably test
> using it when mythfrontend is running normally to find out.
> Are you running LIRC for your remote control?  Does it have a spare
> button that you are not using like the Power button at the top of my
> MCE remote?  If so, you could program LIRC and irexec to use that
> button to execute a command such as "systemctl restart lightdm".  Or
> just "pkill mythfrontend.re".  Or a script that does the pkill first
> and on a second press of the button does the restart command.
> _______________________________________________
> CTRL-ALT-BS is disabled by default but can be enabled with
XKBOPTIONS="terminate:ctrl_alt_bksp" in /etc/default/keyboard

The problem with CTRL-ALT-BS and Myth is that when the system restarts, a
new instance of Myth is created. In testing I could get 10 instances of
Myth running.  The solution is to start Myth but not as a service. This
change can be made in the GUI by editing the auto start command.

On my system, CTRL-ALT-BS does the identical thing as systemctl restart
lightdm from all outward appearances. I see the same text on the terminal
and they both take just a second or so to restart. I have also read that
what the CTRL-ALT-BS function does is restart the X session so I don't
think just restarting X another way is going to solve the problem. I
believe I will still get the 5 minute delay especially considering shutdown
now had the delay.

Any idea what is hanging up the shutdown? More to the point, how do I keep
it from doing it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20190711/9fdedd96/attachment.html>

More information about the mythtv-users mailing list