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

[Stephen Worthington]

On Thu, 24 Dec 2020 23:44:41 -0500, you wrote:

>On 2020-12-24 10:45 p.m., Stephen Worthington wrote:
>> 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.
>
>I may have missed it, but I don't think the OP ever stated whether this 
>was a BE/FE box, or an external FE, trying to talk to the BE. It makes a 
>difference in the config.xml...
>
>Firstly, my config.xml file is basically similar to that above. I did a 
>thorough search to delete all copies except the one in /etc/mythtv/ so 
>as to avoid problems.
>My config.xml differs in minor respects as it is set up to allow outside 
>access to the database:
><Host> is the IP address of the backend and mariadb server box. 
>Localhost is only useful on a BE/FE box, but NOT if you want access from 
>any other FE. The other items in that stanza are the login details for 
>the user from the particular FE, INTO the mariadb server on the <Host> box.
>Of course, if that is not set, then the external FE will never connect. 
>Remember that although you may have a user mythtv on each box (or even 
>your phone!) it is a different user for the mariadb access. Each 
>user/computer combo has to be authorized on the mariadb server.

You have a misconception here.  The Host field in config.xml is only
the address of the database server.  The address of the backend is
stored in the database.  So even on a backend/frontend box, it makes
sense for the config.xml file to have <Host>localhost</Host>, so that
mythbackend will connect to the database using the much faster
localhost connection.  And, in fact, if you specify localhost,
mythbackend has special code that checks for that and then has it
connect via the even faster Unix socket connection to the database.

If you want to have external frontends, the address for the backend in
the database needs to be set to the external IP address of the box.
And the config.xml files on other devices running frontends need to
have the external IP address of the database box (which does not need
to be on the same box as the backend).  And the database needs to be
told to bind to the external IP address of its box as well as to
localhost (bind-address=:: or bind-address=0.0.0.0).

>
>( OT: Gosh I've been at this for a while. I knew I posted an answer 
>about this "some time ago". Turns out it was 14 years ago! So I won't 
>repeat myself: Check it out here:
>
>https://lists.archive.carbon60.com/mythtv/users/214422?search_string=mandamus.org%20mysql;#214422
>
>There is a newer thread (2016) focusing on getting mysql running on a 
>step by step basis, and the backend installed and configured, here:
>
>https://lists.archive.carbon60.com/mythtv/users/601218?search_string=mandamus.org%20mysql;#601218
>
>Both are good for troubleshooting as I tried to do it step by step.
>)
>
>Since your external FE might find the backend has gone to sleep, 
>WakeInLAN should be enabled, and <Command> should be <Command>systemctl 
>restart mariadb.service</Command>
>I have wait time as 2 seconds and retry is 5 to allow the mariadb 
>service to start.
>
>
>Geoff

I do not like the look of "restart mariadb.service".  If the backend
is up and recording, that would likely corrupt the database for that
recording.  Or if it was running mythfilldatabase, the EPG would get
corrupted.  Mariadb should be waking up properly automatically if the
backend box went to sleep.  If that is not happening, then that is
what needs to be fixed.  Or maybe using "start" instead of "restart"
would work - that will only affect mariadb if it is not already
running.  Using "restart" here would only be safe if the frontend
attempted to connect before doing the WOL part and never did that
command if the database connected Ok.  I have never used WOL, so I am
not sure which way it works.

The "restart" command really should be changed to "systemctl restart
mariadb.service" these days also.  The "restart" command is mapped to
"systemctl restart", but that is one extra layer of mapping that is
unnecessary and possible to get broken.