[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