[mythtv-users] What does restarting mythbackend actually do?

Stephen Worthington stephen_agent at jsw.gen.nz
Fri Jan 24 05:10:49 UTC 2020


On Thu, 23 Jan 2020 20:13:16 -0700, you wrote:

>On Thursday, January 23, 2020 7:29:42 PM MST Stephen Worthington wrote:
>> On Thu, 23 Jan 2020 17:24:24 -0700, you wrote:
>> >[ 0.29.1 on Fedora 26 in Canada ]
>> >
>> >I proactively reset my Firewire connection to my HD STB and restart
>> >mythbackend every morning, because I've learned that CNN and sometimes CTV
>> >really mess things up - like yellow or red Watch Recordings entries messes.
>> >Sometimes even that's not enough, so I have to do the reset+restart again
>> >after a failure.
>> >
>> >I've gotten used to it as the price to pay for it to work at all, and I'm
>> >well behind the latest release - I'll be fixing that.
>> >
>> >But, sometimes   systemctl restart mythbackend   takes a couple seconds,
>> >and sometimes it can take a couple minutes, especially after a failure.
>> >
>> >So I'm wondering what's going on with a restart. I'm assuming it has to
>> >wait for various things to be signalled to stop or be killed and whatever
>> >is broken is probably not responding.
>> >
>> >How could I find out what the stop/start sequence is?
>> 
>> Slow restarting of mythbackend is usually caused by a bug that all the
>> MythTV programs seem to suffer from, where they react to an external
>> shutdown request (kill -15 aks kill -SIGTERM) by shutting down all
>> their threads then waiting for that to complete.  Unfortunately, the
>> bug prevents this from working properly and one thread remains
>> running, so mythbackend keeps running until systemd does a timeout on
>> the shutdown process (configurable, 60 or 90 seconds usually).  On
>> timeout, systemd does a kill -9 aka kill -SIGKILL, which kills off the
>> last mythbackend thread.  Since all the other threads have actually
>> shut down properly and the last thread seems to be just waiting
>> forever for it to see that has happened, there is no damage done by
>> this problem, except for the slow shutdown.  This slow mythbackend
>> shutdown is also why MythTV boxes frequently are slow to shutdown or
>> restart - systemd is waiting for the mythbackend timeout before it can
>> complete the shutdown process.
>> 
>> If you want mythbackend to shut down rapidly, you need to issue a
>> second kill -15 shortly after the first one.  I have a script that
>> does this for Ubuntu:
>> 
>> root at mypvr:~# cat /usr/local/bin/mythbackendstop.sh
>> #!/bin/bash
>> 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
>> fi
>> 
>> (Note that my email client wraps long lines - the PID= line is all one
>> long line)
>> 
>> And I have modified my systemd settings for mythbackend so that it
>> uses mythbackendstop.sh to shut down mythbackend.  See this mailing
>> list thread for details and the download URL:
>> 
>> https://lists.gt.net/mythtv/users/628020
>
>Thanks very much! I just did a restart, and it took over 2 minutes! (after 
>recording CNN for 8.5 hours. That didn't happen on 0.28 so much so I might be 
>hitting that bug.
>
>Doing it again took 12 seconds, as you said it would in your post.
>
>> As for your recording problems, if they still continue after upgrading
>> your MythTV version, then you should post details and see if we can
>> help you fix the actual problem, rather than keep on with your nasty
>> workaround of having to restart mythbackend all the time.
>
>I never had to do these proactive restarts before - I used to live with the 
>problem happening every few weeks. But then I started recording a half-dozen 
>hours of CNN and I started getting failed recordings every other day so I 
>started my daily routine. CNN and CTV seem to do bad things. I've chalked it 
>up to using a Shaw-provided DCS-3200MP2 and Firewire (which in most places is 
>disabled) and an old MythTV.
>
>But when I do get up to the latest version (31 I think, before NHL Playoffs 
>start) and I still have the same problems, I will ask more. :)

In the mean time, it should be possible to automatically schedule
daily restarts for when MythTV is not recording.  I have a Python
program:

http://www.jsw.gen.nz/mythtv/gaps

that tells you when a gap in the recordings of a specified size can be
found.  So what you could do is set up a script to be run at say 04:00
daily, then get that script to wait until the time gaps says the next
gap will occur, and then tell systemd to reboot say 2 minutes after
the start of that gap (to allow for any residual mythbackend activity
to stop, and to allow for soft postroll that gaps does not see).


More information about the mythtv-users mailing list