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

Stephen Worthington stephen_agent at jsw.gen.nz
Fri Jul 12 11:09:34 UTC 2019

On Thu, 11 Jul 2019 12:14:49 -0700, you wrote:

>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?

I am not sure exactly what you are talking about here - what are you
getting multiple instances of?  "Myth" is not a very specific term.
Mythfrontend on a Ubuntu system is actually the file
"/usr/bin/mythfrontend.real", and is run by a script
"/usr/bin/mythfrontend", which will automatically restart
"/usr/bin/mythfrontend.real" if it crashes.  So when you kill things
(such as using Ctrl-Alt-BS), you have to be careful that the
"/usr/bin/mythfrontend" script gets killed before
"/usr/bin/mythfrontend.real", or the script will start a new copy of
"/usr/bin/mythfrontend.real".  So you may need to modify the script,
or you may need to run "/usr/bin/mythfrontend.real" directly instead
of using the script, and manually restart it when it crashes.

>Obviously this is a difficult problem to troubleshoot as I have to wait for
>another lock up. But I did a bit of looking and have modified this file
> /etc/systemd/system.conf
>And added this line
>The default is 90 seconds
>My thought is that there were 3 or 4 things that had to time out so it took
>5 minutes. With this change it might take only 12 to 16 seconds.

A good thought.  Mythbackend is one of the things that does not shut
down well when asked to.  It can take quite a while, as systemd waits
for it to shut down, presumably using that timer.  So working out how
to get it to shut down rapidly and modifying its systemd settings for
shutdown would help.  I have suspected for a while that mythbackend
may have the same problem as mythfrontend, and need to be sent two
SIGKILL signals before it will shut down.  But I had never bothered to
test it and find out.  With a bit of searching, I found the "Quickly
terminate mythbackend" section towards the end of this page:


which suggests a way to send two SIGTERMs (kill -15) to mythbackend.
Based on that, and on this:


I did what I think is a better version of that.  I created a
/usr/local/bin/mythbackendstop.sh file:

PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
cut -d= -f2)
if [ "$PID" != "0" ]; then
    kill -15 $PID
    sleep 1
    kill -15 $PID

(The PID= line is all one long line - my email client wraps long

And then added this to my mythtv-backend systemd override.conf file:


It seems to work pretty well, but I have only tested it on my testing
PC so far.

Having too short a timeout for DefaultTimeoutStopSec can be a problem
though - you do want to things like the MySQL/MariaDB database to be
able to shut down safely when asked to do so, and it will not be asked
to stop until mythbackend has stopped.  So it would probably be better
to identify the things that are not shutting down and are being killed
by the DefaultTimeoutStopSec timer, and then adjusting their systemd
units to stop them properly, rather than using a very small
DefaultTimeoutStopSec value.

More information about the mythtv-users mailing list