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

James Abernathy jfabernathy at gmail.com
Wed Dec 19 12:45:09 UTC 2018

On 12/19/18 5:39 AM, Ian Campbell 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?
>>> 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".
> 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.

on my test system NetworkManger is installed and enabled because it's a 
full Ubuntu 18.04.1 fresh install. I went back to my documentation I 
created for my production system and there was a section that I stole 
from some smarter person than myself and it mentions the 
After=NetworkManager-wait-online.service should get the network up 
enough for Mythtv before launching it. However, the mythhdhrrecorder 
goes a lot further out on the network than the original mythtv-backend.

On my production system which is Ubuntu server based (originally 16.04, 
now upgraded in place with 18.04) with no desktop installed, I also have 
Network Manager enabled. I used these instructions which produced a 
workable system back when I had PCIe capture cards and HDHR without 



    Now we need to fix some startup issues because of the move to
    ‘systemd’ instead of the ‘init’ in mythbuntu 16.04. Here’s some
    guidance I used from Stephen Worthington.


    Because I have network tuners and remote frontends, the default
    systemd file for mythtv backend is broken, and needs to be fixed.
      The HVR-2250 is a tuner that has a slow firmware upload, so I will
    likely need to make mythtv backend wait until the tuners are up
    before starting.


    Create a new set of rules for udev that produce systemd events for
    the tuners.  Create a new file in /etc/udev/rules.d.  I have called
    mine 99-mythbackend.rules.  Put this in it:

SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"
SUBSYSTEM=="firewire", TAG+="systemd"


    Create a new directory /etc/systemd/system/mythtv-backend.service.d
    where you put an override file for systemd to override some of the
    settings from the package installed file
    (/lib/systemd/system/mythtv-backend.service) that controls
    mythbackend startup and shutdown.


    Create a new .conf file in the new mythtv-backend.service.d
    directory.  I have called mine mythtv-backend-override.conf.  This
    is what I needed for the HVR-2250 which creates two devices on
    /dev/dvb0 and dev/dvb1:




/The final ‘after’ line tells systemd to wait until NetworkManager has 
the network fully up and running, instead of just the localhost 
interface being up.  That allows mythbackend to find the external IP 
address it is configured for, otherwise it will immediately shut down 
again.  It also means that mythbackend will be able to talk to the HDHR 
tuners, which it does immediately after startup.  If it cannot talk to 
them then, it will mark them as failed and not try to use them after that/.


    I installed NetworkManager; not sure I had, but the next step worked
    better if I did.


    Check if the NetworkManager-wait-online.service is enabled:

systemctl status NetworkManager-wait-online.service

See the "enabled" on the third line.  If that is not present, then you 
need to enable the service:

systemctl enable NetworkManager-wait-online.service


I have not tested:


but will sometime today.  However, since mythhdhrrecorder falls 
completely apart if it can't discover the hdhr tuners using the external 
website, I think I'll keep the ping script and full-internet.service in 

Jim A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20181219/dc15b9fd/attachment.html>

More information about the mythtv-users mailing list