[mythtv-users] mythtv-backend.service startup order

[Stephen Worthington]

On Sat, 15 Feb 2025 00:28:45 -0800, you wrote:

>Anyone else having issues with the startup order on Ubuntu 24.04 LTS and
>mythtv v34, mythtv-backend starts up, but the hdhomerun tuners can't be
>found and some other weird errors in the log. However, doing a "systemctl
>restart mythtv-backend.service" after the system fully boots up, things are
>fine.  After I made the mythtv-backend start up a bit later like after
>apache2, it seems to work fine. I don't quite understand what are the
>missing dependencies in the startup sequence.
>
>Original After= lines...
># systemctl show mythtv-backend.service |grep ^After
>After=sysinit.target system.slice mariadb.service basic.target
>network.target systemd-journald.socket
>
>I am making it depend on apache2 to make it startup later..
># systemctl edit mythtv-backend.service
>Added:
>[Unit]
>After=apache2.service
>
>Generated:
>/etc/systemd/system/mythtv-backend.service.d/override.conf
>[Unit]
>After=apache2.service
>
>Now
># systemctl show mythtv-backend.service |grep ^After
>After=sysinit.target network.target mariadb.service basic.target
>apache2.service systemd-journald.socket system.slice
>
>Startup sequence is fine now.

This is a really old problem now, with lots of solutions on this list
and elsewhere.  Mythbackend does not have the good network code found
in some other programs such as mysql where it will detect changes on
the network interfaces and react to them.  It requires that the
network be actually up and working when it starts, otherwise it will
not set up its network connections, and consequently will not see
network tuners or allow remote mythfrontend connections.  Even if the
network comes up later, it will never re-check to see if it is now
available.

The standard mythtv-backend.service units in various distros normally
only wait for "network.target" before starting mythbackend.  But
"network.target" happens when the first network interface becomes
available.  So when localhost comes up very early (as it is purely a
software interface and does not need to wait for any hardware to be
initialised and working), network.target comes up and mythbackend gets
started.  But it then only sees the localhost interface and can not
connect to the local network.  So to prevent this problem, you need to
get the mythtv-backend.service unit to wait until the specific network
connection(s) it needs are actually working (not just the interface
available, but able to connect to HDHR tuners, for example).

What you have done by making mythbackend wait for apache2 to be up and
running may be OK most of the time, but I suspect that apache2 is one
of those programs that will monitor and react to network interface
changes, in which case it is still possible that the network will at
times not be working well enough for mythbackend when apache2 is
running.  So I would not recommend doing what you are doing.  Instead,
I always recommend a fix that will definitely start mythbackend only
after the required network interface(s) are not only up but are
demonstrably passing packets.

The way I do it is to use a "local-network-pingable.service" that I
wrote that pings a device on the local network and does not come up
until it gets a ping reply.  In my case, I ping my Ethernet switch.
Not all Ethernet switches reply to pings, but in your case you have
HDHRs which should reply to pings.

root at mypvr:/etc/systemd/system# systemctl cat
local-network-pingable.service
# /etc/systemd/system/local-network-pingable.service
[Unit]
Description=Wait for the local network to be pingable
After=network.target

[Service]
Type=simple
# Do not use DNS names here, as the starting of bind9 is dependent on
local-network-pingable.service,
# so DNS lookup is not available until after
local-network-pingable.service succeeds.
ExecStartPre=/bin/bash -c "/usr/local/bin/wait-until-pingable.py
10.0.2.245 30"
ExecStart=/bin/true

[Install]
WantedBy=multi-user.target

Note that the comments about DNS names are unlikely to apply to you -
I run my secondary DNS server on the same PC as mythbackend.

The wait-until-pingable.py program is one I also wrote for myself.  It
is available for download from my web server:

http://www.jsw.gen.nz/mythtv/wait-until-pingable.py

as is a generic version of the local-network-pingable.service file:

http://www.jsw.gen.nz/mythtv/local-network-pingable.service

To set this up run this:

sudo su
cd /usr/local/bin
wget http://www.jsw.gen.nz/mythtv/wait-until-pingable.py
chown root:root wait-until-pingable.py
chmod u=rwx,g=rx,o=rx wait-until-pingable.py
cd /etc/systemd/system
wget http://www.jsw.gen.nz/mythtv/local-network-pingable.service
chown root:root local-network-pingable.service
chmod u=rw,g=r,o=r local-network-pingable.service

Here edit the local-network-pingable.service file and put in the DNS
name or IP address of one of your HDHR tuners or of some other device
that will be pingable on your local network.  Then do:

systemctl edit mythtv-backend

Here edit the mythtv-backend override file.  Delete the existing
"After=apache2.service" line and add these two lines:

Wants=local-network-pingable.service
After=local-network-pingable.service

Save and exit the editor. Then run:

systemctl daemon-reload
systemctl enable --now local-network-pingable.service
exit

Make sure that local-network-pingable.service is working by doing:

sudo systemctl status local-network-pingable.service

Then reboot to check that it is all working properly.