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

[Stephen Worthington]

On Wed, 19 Dec 2018 10:39:20 +0000, you wrote:

>On Wed, 2018-12-19 at 14:33 +1300, Stephen Worthington wrote:
>> 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.
>
>IOW the use of `After=` only, withouit some other `Want=` or similar
>dependency is likely insufficient to ensure the thing is run at all?

Potentially, yes.  It depends on what other unit files do.  All it
takes is one other file to have the Wants= for the same unit, and that
unit will be started.

>> > 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.
>
>This contradicts  
>https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/h which
>says re `network-online.target` (under "How do I make sure that my
>service starts after the network is really online?"):
>
>> This will ensure that all configured network devices are up and have
>> an IP address assigned before the service is started. 
>> network-online.target will time out after 90s. Enabling this might 
>> considerably delay your boot even if the timeout is not reached.
>
>Are you saying the "all configured network devices" statement here is
>incorrect (or somehow misleading?), contrary to what you said below
>(trimmed) it also says "an IP address assigned" not merely "up".

No, it looks like my fingers ran away with me.  I meant
network.target, not network-online.target.  I think
network-online.target must be new, as I have never seen it before.  It
looks useful, but not quite as useful as you might think.  It requires
that either NetworkManager-wait-online.service or
systemd-networkd-wait-online.service be enabled.  In a server that is
using static addresses, neither is likely to be available.  And it
does not check if an Internet connection is available, just that
access to the local network is up.

>Nevertheless, James, have you tried following the suggestions on that
>systemd documentation page, specifically using:
>
>   After=network-online.target
>   Wants=network-online.target
>
>_and_ enabling the `NetworkManager-wait-online.service` (to satisfy the
>network-online.target)? I think that would be:
>
>    # systemctl enable NetworkManager-wait-online.service
>
>According to the page the command to check is:
>
>    # systemctl is-enabled NetworkManager-wait-online.service
>
>I think that is definitately worth trying before getting into other
>more complex workarounds suggested here. If it doesn't work I'd also
>encourage you to report a bug with your distro, at the very least the
>docs need fixing to not so unambiguously recommend this as the approach
>to use if it isn't actually intended to work that way.
>
>> Also, it is fairly common for server PCs not to run NetworkManager,
>
>Note that the OP who I was addressing does appear to be using
>NetworkManager.
>
>Ian.

In the case we are talking about, the use of mythhdhrrecorder requires
not only that the local network be up, but also three more things:

1) DNS is up so that network names can be looked up.
2) An Internet connection is up, so that external DNS names can be
looked up and there is access to the my.hdhomerun.com servers.
3) That my.hdhomerun.com is up and able to respond, so that
mythhdhrrecorder can use it to discover the HDHR tuners on the local
network.

Those extra requirements are what the full-internet.service unit and
the wait-until-pingable.py program are all about.  They allow you to
ensure that my.hdhomerun.com is able to be looked up in the DNS and is
pingable.