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

Wed Dec 19 15:19:11 UTC 2018

On 12/19/18 10:02 AM, Stephen Worthington wrote:
> 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.

I think for safety sake, I'd use the full-internet.service and 
wait-until-pingable.py approach. But since wait-until-pingable.py waits 
for what it wants, the "After=NetworkManager-wait-online.service" could 
really be anything network related because the script waits, right??

-------------------------------------full-internet.service------------------------

[Unit]
Description=Wait for full internet service to be available including DNS
After=NetworkManager-wait-online.service

[Service]
Type=simple
ExecStartPre=/usr/local/bin/wait-until-pingable.py my.hdhomerun.com 30
ExecStart=/bin/true

[Install]
WantedBy=multi-user.target

--------------------------------------------------------------------------------------------