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

R. G. Newbury newbury at mandamus.org
Fri Dec 25 04:44:41 UTC 2020


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.

( 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


More information about the mythtv-users mailing list