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

Darethehair darethehair at gmail.com
Fri Nov 16 19:23:12 UTC 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20121116/a059d192/attachment.html>


More information about the mythtv-users mailing list