[mythtv-users] delaying backend startup until the network is up

[Stephen Worthington]

On Tue, 18 Dec 2018 15:46:40 +0000, you wrote:

>On Mon, 2018-12-10 at 17:03 -0500, James Abernathy wrote:
>> on my production system I use without issue the systemd override
>> provided by. 
>> 
>> sudo systemctl edit mythtv-backend.service
>> 
>> [Unit]
>> After=NetworkManager-wait-online.service
>
>I notice that a lot of the examples (general ones, not myth specific)
>on the web seem to also have a Wants= line with the same target. Is
>there some subtle distinction between having one vs having both lines?
>(I don't run systemd on my myth box and don't really grok this systemd
>thing).

The distinction is not at all subtle.  If you have an "After=" line,
then the unit with that line will not be started until the specified
unit has completed startup.  But if you do not have a "Wants=" (or
"Requires=" or something similar), and there is no other cause for the
Wants= unit to be started, it will not be started, and then your
After= unit will also not be started.  After= sets up ordering between
units.  Wants=, requires= and the like cause startup of other units.

>I also see that the service referenced in [0] is named `network-
>online.service` (but that it says to enable `NetworkManager-wait-
>online.service` to satisfy it). Maybe that doesn't matter and you've
>just harmlessly "dereferenced" one link in a dependency chain.

The network-online.target (not .service) is a systemd "special"
target.  It happens when minimal networking is available.  That
usually means that only the localhost interface is available - to meet
the requirements for network-online.target, only one interface needs
to be available, and localhost is normally the one that comes up first
as it is pure software and does not need to wait for any hardware.  It
is usually quite a long time after localhost comes up before any real
hardware like an Ethernet port can be used, let alone a WiFi
connection.  I really think that the name network-online is a bad
choice, as most people who meet it get misled by it.  A better name
would be "minimal-network-online".

>I'm wondering if maybe the above isn't actually doing as much as you
>hope and it just appear to work because mythbackend (without the
>external recorder stuff) is maybe sufficiently robust that it copes .
>e.g. perhaps the backend is happy if the interface is merely up but not
>yet configured when it starts, but the external recorder stuff isn't
>etc.

If you are using MythTV in a combined backend/frontend only setup,
where there are no external frontends, and you also have no network
tuners, then all you need is localhost and MythTV can work properly.
So the MythTV packages only specify network-online.target.  But if you
need a real network interface up so that mythbackend can bind to it
when it starts, then you need a better target to wait for that tells
you when networking is up enough for that to work.  If you are using
NetworkManager, NetworkManager can tell you when it has finished
bringing up all the interfaces it controls, and you can enable and use
NetworkManager-wait-online.service to wait for.

But when NetworkManager-wait-online.service is up, all that means is
that all the interfaces NetworkManager controls are up.  It does not
mean that the Internet is reachable from the PC.  An unplugged
Ethernet cable, or an ISP outage could mean that the PC is isolated
from its local network, or that it is isolated from the Internet.  For
the HDHR tuner discovery in mythhdhrrecorder to work, access to the
my.hdhormerun.com site is needed.  So that is what this thread is
about - how you ensure that access to my.hdhomerun.com is available
before you start mythbackend (and mythbackend then runs
mythhdhrrecorder during its startup when it tests if its tuners are
available).  If any tuner (including mythhdhrrecorder tuners) is not
working when mythbackend tests it at startup, it will be marked as
unavailable and will not be used.  Mythbackend never goes back later
to try tuners again - the status at startup is all it checks for and
knows about.

Also, it is fairly common for server PCs not to run NetworkManager,
but instead use static IP addresses.  If you are running your DNS
server on a box, you do not want its addresses to ever change.  And if
a box is running your DHCP server, it can not have DHCP addresses.
Hence the need for such server boxes to use static addresses.  A
mythbackend box is a good candidate to use as such a server box,
because it will often be on 24/7.  My MythTV box is like that - it is
a DNS and NTP server, and has static IP addresses.  So I can not tell
on that box when the local networking is up by using
NetworkManager-wait-online.service because it does not use
NetworkManager.  I get around that problem by having mythbackend wait
for minisatip.service to have started.  Minisatip is the SAT>IP server
software that runs my DVB-S2 tuners and provides a network interface
to them.  Unlike mythbackend, it has code internally that allows it to
wait for its specified network interfaces to be up and really working
before it binds them.  So that allows mythbackend to know its network
tuners are up when minisatip has finished starting up.

If mythbackend was (much) more intelligent about setting up its
networking, there would be no need for messing around getting systemd
to wait for the network to be up before starting it.  MySQL does not
need any of that, because it has sophisticated networking code.  MySQL
is set up to detect the network up/down events and then check its
specified network interfaces.  If one has come up or gone down, it
changes its setup to match and carries on serving on all the available
interfaces.  Mythbackend could be made to do the same, if one of the
devs would be able to put enough time into getting it working like
that.  The problem is that the devs do not have enough time for rather
more important things, and I think there may not be a dev that has
ever done code like that before anyway.

And in any case, mythhdhrrecorder is an external tuner, and
mythbackend currently has no way of knowing that it requires
networking to be up before it can work.  And it especially does not
know that mythhdhrrecorder needs to be able to talk to
my.hdhomerun.com before it should be allowed to start.  I can not see
that mythbackend will ever have a way for an external recorder to
specify such a requirement to mythbackend.

>Ian.
>
>[0] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/