[mythtv-users] : MythTV backend service started before network is functional

Stephen Worthington stephen_agent at jsw.gen.nz
Wed Aug 7 01:49:07 UTC 2019


On Tue, 6 Aug 2019 17:38:33 -0400, you wrote:

>> Date: Tue, 06 Aug 2019 19:25:33 +1200
>> From: Stephen Worthington<stephen_agent at jsw.gen.nz>
>> To: Discussion about MythTV<mythtv-users at mythtv.org>
>> Subject: Re: [mythtv-users] Fwd: MythTV backend service started before
>> 	network is functional
>> Message-ID:<kp8ikepn33al4k9d59ia57075c4u3mgv9i at 4ax.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Mon, 5 Aug 2019 15:09:22 -0400, you wrote:
>>
>>> Stephen,
>>>
>>> A few questions.
>>>
>>> 1) Why doesn't stopping and stopping mythtv-backend' service fix this
>>> issue? Is the tuner permanently marked as 'bad' barring a reboot. Note
>>> that the reboot runs into the same issue.
>> If stopping and restarting mythbackend does not fix the problem, then
>> it is not the race condition.  But you do need to be sure that you
>> have actually stopped and restarted mythbackend.  In 14.04, how you do
>> that is rather different as it does not use systemd, and also not init
>> scripts except as a fallback option, but instead a different system
>> again, called Upstart.
>>
>> So to do the check that restarting mythbackend fixes the problem and
>> hence you are getting the race condition, this is what you need to do:
>>
>> Check that mythbackend is running now:
>>
>>    ps -e | grep mythbackend
>>
>> Then stop mythbackend:
>>
>>    sudo stop mythtv-backend
>>
>> and verify that it has stopped:
>>
>>    ps -e | grep mythbackend
>>
>> and start mythbackend again:
>>
>>    start mythtv-backend
>>
>> and verify that mythbackend is running again:
>>
>>    ps -e | grep mythbackend
>>
>> Note that the "service xxxxx start" commands also work, but only
>> indirectly.  The correct commands to use with Upstart are "start",
>> "stop", "status" and "restart".
>You can see from my question below that I have tried stopping and 
>restarting the backend. I did it with 'service' and 'update-rc.d' but 
>that did not seem to help for some reason.

But did you actually check that mythbackend had stopped and restarted?
The reason I ask that question is that using "service" and
"update-rc.d" are not the correct ways of controlling a service run by
Upstart and have problems doing that.  So they are not necessarily
going to have worked.  "Service" should have worked, but my experience
was that it did not always work.  I never looked at why as I just used
the correct Upstart "start" and "stop" commands.

And "update-rc.d" will not work - it is for running init scripts in
/etc/init.d, and will not control anything being run by Upstart from a
/etc/init configuration file.  It also does not start and stop init
scripts.  It enables and disables them.  To start and stop an init
script, you need to do:

/etc/init.d/<script name> start
/etc/init.d/<script name> stop

>>> 2) I have ubuntu 14.04 (upgraded from 12.04) and it seems to be half way
>>> into systemd and so 'systemctl' is unavailable. The backend seems to ave
>>> been stopped and started with 'service mythtv-backend start'.
>>> 'NetworkManager-wait-online.service' you refer to in your solution seems
>>> to be unavailable as well. I see that the
>>> '/etc/init/mythtv-backend.conf' has the following line....
>>>
>>> start on (local-filesystems and *net-device-up IFACE!=lo *and started
>>> udev-finish)
>>>
>>> Doesn't this ensure that network access to all non-loopback devices are
>>> up before mythtv-backend is started? Why is there a need for the
>>> additional checks in your solution. Am I missing something?
>> I theory it should work, but when I checked my old 14.04.5 partition,
>> I can see that this is what I had:
>>
>> #start on (local-filesystems and net-device-up IFACE!=lo and started
>> udev-finish)
>> start on (local-filesystems and net-device-up IFACE=eth0 and
>> net-device-up IFACE=br0 and net-device-up IFACE=eth1 and started
>> udev-finish)
>> stop on runlevel [016]
>>
>> So I have commented out the default "start on" line and replaced it
>> with one that specifically specifies all the network devices to wait
>> on.  In my case that is eth0, eth1 and tap0, due to how that PC does
>> other networking and routing functions (it is my OpenVPN server).  In
>> your case, you would probably only want to make it wait on eth0 (or
>> whatever the name of your Ethernet interface is).  I am pretty sure
>> that I had to do that as the default "start on" line did not work
>> properly.
>>
>> How many network interfaces does your MythTV box have?  If it only has
>> localhost and one Ethernet interface, then the default "start on" line
>> should work.  If it has more than one Ethernet interface, or also has
>> other interfaces such as WiFi or virtual ones such as my tap0
>> interface for OpenVPN, then the default "start on" line will allow
>> mythbackend to start when any of the other interfaces is up, not only
>> after the Ethernet interface used to talk to the tuners is up.
>I have both ethernet and wireless network interface on this desktop but 
>both connect the same router where my network tuner (HDHR) is connected. 
>If wireless is connected, the backend should be able to see the HDHR 
>through the wireless connection.
>>> Thanks again for your help
>> Have you upgraded the PC to boot from an SSD?  That causes all sorts
>> of changes to the timing of things, and Upstart was never optimised
>> for that.
>
>No I did not. I have the plain old spinning disk.  For now I added a 
>sleep line to "/etc/init/mythtv-backend.conf"  at the pre-start section 
>as below:
>
>pre-start script
>     sleep 10 # Added sleep to allow for network to be operational 
>during reboot before backend
>
>and this seems to work. I tried multiple reboots to test it.
>
>Thanks

Yes. using a "sleep" will normally work.  Until it does not.  If it is
the race condition, like all race conditions it will be variable
depending on what is happening at startup.  So one day it will likely
take a bit longer than the 10 seconds you have allowed and will hit
you again.  Long experience by me and anyone else who deals with race
conditions frequently says that they are very tricky and a fixed delay
is *never* a safe option.  You need to fix the condition properly.  So
instead of adding a sleep, you should be adding a ping of one of your
network tuners, and waiting for a response from the tuner before you
allow mythbackend to start.

Also, a completely different subject, having two different routes for
your network traffic (via Ethernet and via WiFi) has a number of
interesting complications itself.  Hopefully the network is
intelligent enough to set up the route via Ethernet as having priority
over the route via WiFi, but it would pay to run this command:

route -n

to check.  If the "metric" values for the Ethernet interface are lower
than the metric values for the WiFi, all is good.

And if that PC is able to route traffic between its interfaces (not
the default, so you would have had to enable it), the life of packets
on your network could get very interesting unless you are running
proper routing protocols such as RIP or OSPF.


More information about the mythtv-users mailing list