Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#31846 - [mythtv] Mythbackend needs to wait for network before starting on fast systems.

Attached to Project: Community Packages
Opened by John (graysky) - Monday, 08 October 2012, 19:03 GMT
Last edited by György Balló (City-busz) - Monday, 09 December 2013, 20:31 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jonathan Conder (PirateJonno)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Since the 0.26-1 update, mythbackend is much more picky about having a network interface up before it starts. I believe main protocol server in mythbackend terminates, taking the backend with it, when it does not have access to the IP addresses it on which it was told to listen. I have an SSD-based backend that boots pretty quick. The problem is that my network isn't ready when mythbackend starts which causes the backend to detect no network and shutdown.

I can fix this by starting the backend manually several seconds after the box boots via the attached script that is triggered when X comes up. I know that this is not a robust and general solution. Perhaps adding a user-configurable delay into the mythbackend.service file and into the sysv init script the will accomplish the same thing?

Additional info:
* package version(s) 0.26-1
* config and/or log files etc.

Here is a snipette from my backend log if I do NOT use the script which clearly shows the issue:

2012-10-07 15:07:52.606487 C ServerPool: Host is configured to listen on, but address is not used on any local network interfaces.
2012-10-07 15:07:52.606648 I Listening on TCP
2012-10-07 15:07:52.606712 I Listening on TCP [::1]:6544
2012-10-07 15:07:52.641782 I Added logging to mythlogserver at TCP:35327
2012-10-07 15:07:53.806462 E Bonjour: Error: -65537
2012-10-07 15:07:53.806474 E Bonjour: Failed to register service.
2012-10-07 15:07:53.806485 I Main::Registering HttpStatus Extension
2012-10-07 15:07:53.811393 C Backend exiting, MainServer

Steps to reproduce:

Boot using a relative fast system on an SSD. I would say you need to use systemd, but I can replicate this error with sysv.
This task depends upon

Closed by  György Balló (City-busz)
Monday, 09 December 2013, 20:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  mythtv 1:0.27-5 (see my last comment)
Comment by John (graysky) - Monday, 08 October 2012, 19:17 GMT
I also opened a bug report with upstream since this is really an upstream issue. Is it appropriate to add a fix to our packages as a temp fix? I have no idea when or if upstream plans to take this on at the mythbackend-protocol level or not.
Comment by John (graysky) - Wednesday, 10 October 2012, 01:31 GMT
Looks like they are putting the blame back on us...

"If mythbackend is started before your network is available for use, then your init scripts or init system are broken, and the problem lies with your packager. If you do not require remote access that would need the network to be up when mythbackend is started, simply tell MythTV to listen on the localhost addresses only."
Comment by John (graysky) - Sunday, 14 October 2012, 14:24 GMT
There is no need for further follow-up. The source of my problem was using a network.service I made per a suggestion on

In short, configuring the network this way causes systemd to not detect when the network is up and can have down-stream consequences on daemons that require an active network such as mythbackend in [community]/mythtv for example.

USERS SHOULD MAKE USE OF [core]/netcfg FOR STATIC CONFIGURATIONS. I have edited the wiki.
Comment by Jonathan Conder (PirateJonno) - Monday, 15 October 2012, 05:57 GMT
Thanks for sorting this out. Let me know if anything else goes wrong.
Comment by John (graysky) - Wednesday, 14 November 2012, 23:54 GMT
  • Field changed: Percent Complete (100% → 0%)
My fix is not working. This bug should be reopened. Another bug that is related if not the same is
Comment by Jonathan Conder (PirateJonno) - Monday, 26 November 2012, 01:35 GMT
I'm not sure what I'm supposed to do to fix this (without affecting people who don't use netcfg)
Comment by John (graysky) - Monday, 24 December 2012, 13:49 GMT
Wish I knew... Now the only way my system boot properly is WITHOUT the mythbackend.service - I have to run it on a the script I posted initially.
Comment by Jonathan Conder (PirateJonno) - Tuesday, 09 April 2013, 09:55 GMT
Is this still an issue? If so, what can I do about it? If not, can I close the bug?
Comment by John (graysky) - Wednesday, 10 April 2013, 15:48 GMT
Jon - No idea... I am still using my custom service; the package provided one does not work for me.
Comment by György Balló (City-busz) - Tuesday, 10 September 2013, 12:47 GMT
We may should add to Wants=:

But I'm not sure that it would solve the problem for all network management software, because AFAIK this target is provided only by NetworkManager-wait-online.service:
Comment by Jonathan Conder (PirateJonno) - Tuesday, 10 September 2013, 16:34 GMT
When I was using NetworkManager, mythtv started just fine. That said, I wasn't using an SSD. If anyone reports having problems with NM, I'll add to the next build.
Comment by György Balló (City-busz) - Tuesday, 10 September 2013, 19:13 GMT
Then I think it's time to close this bug. If anyone has this bug, and uses NetworkManager, then run:
# systemctl enable NetworkManager-wait-online

It should works even with the current unit file. If you are using another network management software, then open an upstream feature request to provide a -wait-online service for that network management software.
Comment by Jonathan Conder (PirateJonno) - Wednesday, 11 September 2013, 00:30 GMT
Ok, suits me.
Comment by John (graysky) - Saturday, 30 November 2013, 18:28 GMT
  • Field changed: Percent Complete (100% → 0%)
Now that netctl is the standard, this problem is still present but is solved by changing to
Comment by John (graysky) - Saturday, 30 November 2013, 18:35 GMT
I should add that I STILL have to use a dirty hack to allow other frontend systems to connect even with this recent modification. If I do not, I have to manually restart mythbackend.service some time after the machine boots.

My workaround:
1) Disable mythbackend.service.
2) Run the attached as the mythtv user in ~/.config/autostart which handles it.
Comment by György Balló (City-busz) - Monday, 09 December 2013, 20:26 GMT
Now I added to mythbackend service file in mythtv version 1:0.27-5.

If you are still experiencing problems, then open a feature request for your actual network manager to implement the via a service file.