mythtv backend wouldn't start automatically after the latest update

Bug #907301 reported by limcearna
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mythbuntu
Won't Fix
Undecided
Unassigned

Bug Description

Mythtv Backend doesn't start on machine boot.
The mythtv-backend.conf in /etc/init doesn't trigger, at least on my setup.
I think the "start on" conditions are not being met.
Latest version: 2:0.24.1+fixes.20111207.40f3bae-0ubuntu0mythbuntu1
Attached is a version that works on my server, with changed "start on"
conditions

Revision history for this message
limcearna (limcearna) wrote :
Revision history for this message
Thomas Mashos (tgm4883) wrote :

Wouldn't that start when lo is up? What network devices do you have?

Revision history for this message
limcearna (limcearna) wrote :

lo is up. I have lo, eth0 and wlan0

Revision history for this message
limcearna (limcearna) wrote :

The rule defined in the current file in the distribution is IFACE!=lo. I'm new to upstart but that would indicate to me that we're expecting lo not to be up.

It is as per the Upstart doc (http://upstart.ubuntu.com/cookbook/#id175) but not as per the "Startup Process" (http://upstart.ubuntu.com/cookbook/#id123)

If I set it to IFACE!=lo it won't start.
It starts when I set it to IFACE=lo and started udev-finish

Should this be the configuration?

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Mythbuntu-bugs] [Bug 907301] Re: mythtv backend wouldn't start automatically after the latest update

The intention for the rule is to start when an interface that isn't lo
comes up (be it eth0, wlan0, what not). It sounds like at least for your
scenario that doesn't work properly.

We don't want to trigger on lo itself.

On Tue, Dec 27, 2011 at 15:11, limcearna <email address hidden> wrote:

> The rule defined in the current file in the distribution is IFACE!=lo.
> I'm new to upstart but that would indicate to me that we're expecting lo
> not to be up.
>
> It is as per the Upstart doc (http://upstart.ubuntu.com/cookbook/#id175)
> but not as per the "Startup Process"
> (http://upstart.ubuntu.com/cookbook/#id123)
>
> If I set it to IFACE!=lo it won't start.
> It starts when I set it to IFACE=lo and started udev-finish
>
> Should this be the configuration?
>
> --
> You received this bug notification because you are a member of Mythbuntu
> Bug Team, which is subscribed to Mythbuntu.
> https://bugs.launchpad.net/bugs/907301
>
> Title:
> mythtv backend wouldn't start automatically after the latest update
>
> Status in Mythbuntu, Ubuntu derivative focused upon MythTV:
> New
>
> Bug description:
> Mythtv Backend doesn't start on machine boot.
> The mythtv-backend.conf in /etc/init doesn't trigger, at least on my
> setup.
> I think the "start on" conditions are not being met.
> Latest version: 2:0.24.1+fixes.20111207.40f3bae-0ubuntu0mythbuntu1
> Attached is a version that works on my server, with changed "start on"
> conditions
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mythbuntu/+bug/907301/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~mythbuntu-bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~mythbuntu-bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Mario Limonciello
<email address hidden>

Revision history for this message
Chris Sadler (chris-g-sadler) wrote :

Same for me.
Last 2 sets of updates i've downloaded from the official mythbuntu repositories (3/2/12 & a week ealier) broke my mythbuntu box.

Its 11.04 x64 running as a stand alone backend & front end (no network access) running kernal 2.6.38-13.
The above solution worked for me. Once I changed the init rule as limcearna above it worked beautifully...
(got in a lot of trouble from the other half as well, because I did the updates and went away for the week, leaving her unable to watch tv or record programs... )

mythtv 2:0.24+fixes.20120131.a6727fc

Thanks for this bug report, by the way, i would've spent hours trying to solve this. there was absolutely nothing that i could find in the system or mythtv logs (obviously because the system didn't think the upstart job was supposed to run)

Revision history for this message
Radoslaw (radraw) wrote :

#5 "The intention for the rule is to start when an interface that isn't lo
comes up (be it eth0, wlan0, what not)"

I don't understand this inention. On single machine setup it is sufficient to have myth backend listening on localhost, and this rule breaks such setup with unknown reason.

Revision history for this message
Thomas Mashos (tgm4883) wrote :

#7 yes, on a single machine it is sufficient to listen on lo, however it is also sufficient to listen on the regular nic interface. On multiple machine installs it is never OK to just listen on lo (for obvious reasons). For this reason we've decided to make the setting "anything but lo" rather than "lo" as the only time this wouldn't be valid is on machines without any nic (which is far less common)

Fit some reason on your systems, it isn't sending the signal saying something other than lo has started (that is my guys anyway). I'd be interested what happens in the following cases

1) you manually send the signal
2) you attempt a 'sudo service mythtv-backend start' after the system is booted

Also, can someone upload their /var/log/upstart/mythtv-backend.log file after it has failed to start at boot.

Revision history for this message
Thomas Mashos (tgm4883) wrote :

We really do appreciate you opening this ticket to help improve Mythbuntu, but it needs to be closed for a number of reasons. The biggest one is that upstream believes this to be fixed in the latest version. Could you please verify if this issue still exists in the latest version?

Please do not let the closing of this ticket dissuade you from opening a new ticket if this (or any other) problem occurs with the newer versions.

Changed in mythbuntu:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.