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

[Stephen Worthington]

On Thu, 24 Dec 2020 15:58:17 -0500, you wrote:

>On 2020-12-23 10:30 p.m., Stephen Worthington wrote:
>> 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.
>
>Because it was not told to try again (Restart=Always) or it tried to, 
>the number of times it was told to try (all in a very short time, 
>usually), and those attempts also failed.
>
><snip>
>> 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.
>
>
>The [Unit] section of my mythbackend.service file has this:
>[Unit]
>Description=MythTV backend service
>After=network-online.target mariadb.service mysqld.service time-sync.target
># Uncomment the following line if you will be using the mythweb plugin 
>on the
># same system as mythbackend.
>Wants=httpd.service
>
>That set of 'After' requirements will exactly fix the startup problem 
>which it appears you are experiencing. Stephen is correct about Restart, 
>but that does not deal with the real problem, which is that your system 
>is attempting to start mythbackend when the dependencies are not yet 
>ready. The Restart settings are a parallel workaround, but not 
>guaranteed to work in all cases (such as an external mariadb box, which 
>is slow to respond, causing the mysql client on the mythbox to take a 
>long time... or even a login error between the mysql client box and the 
>mysql server...)
>Geoff

My guess would be that time-sync.target is what is fixing things. That
means that networking has been up long enough for the ntp daemon to
exchange packets with at least one other time service.  Which means
that external networking is up and actually working.  The external
time service could be another box on the local network, but unless you
have set the ntp config for that, it will likely be Internet time
services.

In my Fedora 33 VM, I have mythbackend starting properly using an IPTV
tuner.  Note that mythbackend does not actually test IPTV tuners
during startup, so mythbackend probably does not need networking to be
fully up (external IP addresses available) in order to start with this
config.  Mythbackend does not fail and restart at all, and I have not
changed its systemd config.  The /etc/mythtv/config.xml file is
currently:

<Configuration>
  <UPnP>
    <UDN>
      <MediaRenderer></MediaRenderer>
    </UDN>
  </UPnP>
  <Database>
    <UserName>mythtv</UserName>
    <PingHost>0</PingHost>
    <Host>localhost</Host>
    <DatabaseName>mythconverg</DatabaseName>
    <Password>********</Password>
    <Port>3306</Port>
  </Database>
  <WakeOnLan>
    <Enabled>0</Enabled>
    <SQLReconnectWaitTime>0</SQLReconnectWaitTime>
    <SQLConnectRetry>5</SQLConnectRetry>
    <Command>echo 'WOLsqlServerCommand not set'</Command>
  </WakeOnLan>
</Configuration>

I had to create that manually by copying and exiting the config.xml
from my main Ubuntu MythTV box as the MythTV packages and mythtv-setup
failed to create it.  Looking at the config.xml options, setting the
PingHost option might also be a good idea as it means that mythbackend
will try to ping the Host address before going any further trying to
connect to the database.

I still have to try with using the external IP address of the VM as
the database connection - that is where I think I will get problems.