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

[James Abernathy]

On Sat, Feb 15, 2025 at 6:08 AM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> 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.


I use 2 different solutions depending on the tuner.  On my production
backend with a PCIe tuner card I use Stephen's solution mentioned above.

On my test systems with HDHomerun tuners I use the one I posted on the
Mythtv forum.
https://forum.mythtv.org/viewtopic.php?f=29&t=5846

JIm A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20250215/1f2dd63b/attachment-0001.htm>