[mythtv-users] Auto-started Mythbackend = Remote Mythfrontend connection failure

Thomas Mashos thomas at mashos.com
Fri Nov 16 21:05:50 UTC 2012


On Fri, Nov 16, 2012 at 11:23 AM, Darethehair <darethehair at gmail.com> wrote:

>  On 16/11/12 10:41 AM, Thomas Mashos wrote:
>
> That doesn't make sense, there is nothing that would have the
> NetworkManager depend on the backend to start (the networking start scripts
> are what is used in regular Ubuntu without any MythTV). What happens if you
> remove the script you added to check the network and then just stuck a 'sleep
> 300' (5 minutes) in the backend upstart script right before the backend
> starts?
>
> Thanks,
>
> Thomas Mashos
>
> Adding a 300s delay in the 'mythtv-backend' script just makes the boot
> take 5 minutes longer -- including the start of the 'network-manager' :(
>
> However, through some deep digging, I have found a solution -- and I am
> very curious whether (at least part of) this could be applied to future
> packaging of MythTV to avoid problems for others...
>
> In my case, there were two parts to the solution:
>
> 1) An understanding that Linux Debian has moved to a 'dependency based
> boot sequence' methology:
>
> http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
> http://wiki.debian.org/LSBInitScripts
>
> Previously, it used an older (SysV?) approach where the scripts in the
> various runlevel 'rcN.d' directories were run in alphabetic order.  In this
> older system, I also would have had problems, since 'S21m' occurs before
> 'S21n':
>
> darren at frodo2 /etc/rc2.d $ ls -1
> ...
> S21mythtv-backend
> S21network-manager
> ...
>
> OK, so I checked what the newer 'LSB' fields were in the 'mythtv-backend'
> script:
>
> ### BEGIN INIT INFO
> # Provides:          mythtv-backend
> # Required-Start:    $local_fs $remote_fs
> # Required-Stop:     $local_fs $remote_fs
> # Should-Start:      mysql
> # Should-Stop:       mysql
> # Default-Start:     2 3 4 5
> # Default-Stop:      0 1 6
> # Short-Description: Start/Stop the MythTV server.
> ### END INIT INFO
>
> I changed it slightly so that 'network-manager' is a 'required'
> prerequisite:
>
> ### BEGIN INIT INFO
> # Provides:          mythtv-backend
> # Required-Start:    $local_fs $remote_fs network-manager
> # Required-Stop:     $local_fs $remote_fs network-manager
> # Should-Start:      mysql
> # Should-Stop:       mysql
> # Default-Start:     2 3 4 5
> # Default-Stop:      0 1 6
> # Short-Description: Start/Stop the MythTV server.
> ### END INIT INFO
>
> I then ran the following command (I think it is required after making
> script changes like that):
>
> darren at frodo2 /etc/init.d $ sudo update-rc.d mythtv-backend defaults
>
> This appears to have changed the naming of the script in '/etc/rc2.d' so
> that it is alphabetically *after* the network start:
>
> darren at frodo2 /etc/rc2.d $ ls -1
> ...
> S21network-manager
> ...
> S22mythtv-backend
> ...
>
> A reboot confirms the new order:
>
> darren at frodo1 /etc/rc2.d $ sudo sed $'s/\^\[/\E/g;s/\[1G\[/\[27G\[/'
> /var/log/boo
> ...
> Fri Nov 16 12:57:01 2012: [ ok ] Starting MySQL database server: mysqld .
> ..
> Fri Nov 16 12:57:05 2012: [info] Checking for tables which need an
> upgrade, are corrupt or were
> Fri Nov 16 12:57:05 2012: not closed cleanly..
> Fri Nov 16 12:57:05 2012: [ ok ] Starting network connection manager:
> NetworkManager.
> Fri Nov 16 12:57:06 2012: [ ok ] Starting MDM Display Manager: mdm.
> Fri Nov 16 12:57:16 2012: Starting MythTV server: mythbackend .
> ...
>
> I found out from experimention that merely manually renaming the scripts
> in '/etc/rc2.d' wasn't good enough -- those 'LSB' fields are required.
>
> Not sure what the (say) Ubuntu scripts order system is, so I think that
> what I said above doesn't apply to those folks.
>
> 2) Though I was very optimistic that the above would solve all my
> problems, it did not.  Apparently, waiting for 'network-manager' to start
> isn't quite good enough.  So I added my home-made script back into
> 'mythtv-backend':
>
> #! /bin/sh
> /usr/local/bin/wait4net.sh 60 > /tmp/wait4net.out 2> /tmp/wait4net.err
> ...
>
> After rebooting again, I saw the fruits of my labors i.e. it took about
> another 5s for the wireless IP address to be established:
>
> darren at frodo1 /etc/init.d $ cat /tmp/wait4net.out
> Fri Nov 16 12:57:12 CST 2012 not yet! attempt: 1
> Fri Nov 16 12:57:13 CST 2012 not yet! attempt: 2
> Fri Nov 16 12:57:14 CST 2012 not yet! attempt: 3
> Fri Nov 16 12:57:15 CST 2012 not yet! attempt: 4
> Fri Nov 16 12:57:16 CST 2012 not yet! attempt: 5
> Fri Nov 16 12:57:16 CST 2012 success! after attempt: 6
> ...
> wlan1     Link encap:Ethernet  HWaddr 00:14:d1:36:cf:c8
>           inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
>           inet6 addr: fe80::214:d1ff:fe36:cfc8/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:670 (670.0 B)  TX bytes:1114 (1.0 KiB)
>
> On my remote frontend, 'mythfrontend' started up fine with no more
> connection errors!
>
> Comments anyone?  Does part #1 of my solution make sense for Debian folks
> running MythTV?
>
> Thanks
>
>
Sorry for the confusion. I responded to Nick Rout claiming this should be
resolved by the Ubuntu/Debian packagers, and confused what we were talking
about (which is Linux Mint Debian Edition).

Debian does not use Upstart by default, so anything I've said mentioning
the Upstart scripts won't apply unless you've switched it to use Upstart
rather than Sysvinit. Because of this you've got to muck around with these
startup scripts to get everything set in the proper order with enough
delays so everything can start properly.

Ubuntu uses Upstart, so (obviously) anything I've said about Upstart
applies here, including the bits where the MythTV Backend startup scripts
DEPEND on the networking stack to be up. Thus if the OP had been using
Ubuntu, this wouldn't have happened (unless the stack was up, but the DHCP
server was really slow to give out an address).

So in conclusion, my bad for forgetting the OS we were talking about.

Thanks,

Thomas Mashos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20121116/45aaf612/attachment-0001.html>


More information about the mythtv-users mailing list