[mythtv-users] SystemD (Was: Recommended Linux Distro post CentOS)

[Stephen Worthington]

On Wed, 23 Dec 2020 17:10:43 -0700, you wrote:

>On Sun, Dec 20, 2020 at 02:39:17PM +1300, Stephen Worthington wrote:
>> How about giving us a bit more detail about the problem so we can
>> help?  The output into mythbackend.log and the output of "journalctl
>> -eu mythbackend" would be a start.  And "systemctl cat mythbackend",
>> so we can see exactly what the unit files are.
>
>I've pretty much given up trying to get systemd to work.  This was a year or
>two ago and my recollection matches what Geoff had posted that mythbackend
>wasn't starting because mariadb wasn't really ready.  That's your main
>guess as well.  I'm not particularly concerned about that, but rather
>why systemd doesn't try to run mythbackend again.
>
>> Using "Restart=always" can be a big problem when you run up against a
>> new bug in an update of a program that causes it to crash at startup.
>> It will then keep on restarting and filling up the logs, until the
>> logs fill the partition and the system dies.  So it is normally best
>> to set a maximum number of retries.  I would suggest that you add
>> something like:
>> 
>> [Service]
>> StartLimitBurst=10
>> StartLimitInterval=60s
>> 
>> to prevent that.
>
>I may try this sometime, although it's addressing an issue of systemd
>getting run away restarting mythbackend, which is the opposite to my
>issue.  The mythtv system seems to get rebooted once or twice a year,
>and I've just resigned myself to having to manually start mythbackend
>whenever that happens.  It's the path of least resistance at this point.
>
>marcus hall
>marcus at tuells.org

I installed Fedora 33 in a virtual machine a few days ago, but have
not got MythTV installed properly yet - there seems to be a problem
with the RPMFusion packages and they did not set up the
/etc/mythtv/config.xml file and did not create the database.  I did
notice that there is a warning in the mythbackend.service file:

# MariaDB seems to have a systemd related bug and tells systemd that
it is
# ready to accept connections before it really is. If you have this
problem
# try uncommenting the following lines:
# Restart=on-failure
# StartLimitBurst=5
# StartLimitInterval=1

which seems to be about the problem you are experiencing.  So I am
guessing that mariadb is telling systemd it is up when it is not yet
able to be connected to via networking - it probably only has its Unix
socket connection up, and networking is still to come up properly.
This does not happen in Ubuntu, so I think this is a Fedora bug.  In
any case, my guess is that when mythbackend.service starts
mythbackend, it is unable to connect to the database and shuts down
again.  Looking at the mythbackend.log file or the output of
"journalctl -eu mythbackend" should tell if that is the case.  If you
then uncomment those lines in mythbackend.service, or better, create
an override file using "sudo systemctl edit mythbackend", then
mythbackend will be restarted up to 5 times fairly rapidly.  But if
networking is still not up and it still can not connect to mariadb,
then mythbackend.service will fail and systemd will not keep on trying
to restart mythbackend.  I am guessing that the default values for
StartLimitBurst and StartLimitInterval on Fedora are such that the
mythbackend restarts all happen before networking is actually up, so
mythbackend is never restarted after networking is finally up.

So the above settings are not a good workaround at all.  It would be
better to use something like this:

Restart=on-failure
RestartSec=5
StartLimitBurst=5
StartLimitInterval=30

What that does is to change the RestartSec from its default of 100 ms,
so that restarts are done only very 5 seconds.  Then it increases the
StartLimitInterval to account for that change which means that 5
restarts done at 5 s intervals takes 25 seconds, then mythbackend
needs time to start.

However, as with all race conditions, it is never a good idea to use
delays to fix them.  The proper fix would be to get
mythbackend.service to actually wait for networking to be up before it
allows mythbackend to be started.  One way to do that is to use my fix
that works on Ubuntu for this when people are using network tuners or
external frontends.  If you are not set up to use network tuners or
external frontends, you would just set the ping target to be localhost
(127.0.0.1).  I am going to try this out as soon as I can work out how
to get the mythtv packages to install correctly.