[mythtv-users] Can't start backend on Debian 9 (Stretch)

Fri Jul 28 08:58:36 UTC 2017

On 28/07/17 01:26, Stephen Worthington wrote:
> On Thu, 27 Jul 2017 16:04:26 -0500, you wrote:
>
>> On Thu, Jul 27, 2017 at 3:19 PM, Mike Perkins <mikep at randomtraveller.org.uk>
>> wrote:
>>
>>> On 27/07/17 20:05, Ian Campbell wrote:
>>>
>>>> On Thu, 2017-07-27 at 19:59 +0100, Ian Campbell wrote:
>>>>
>>>>>
>>>>> I would expect that even LSB compat based stuff would show up on
>>>>> systemd based systems in things like "systemctl" and "system status"
>>>>> output, and with that you should be able to find the name it has given
>>>>> the compat unit for use with journalctl (I think it's "-u <unit>" to
>>>>> inspect a particular unit, but I don't have a running systemd system to
>>>>> check on).
>>>>>
>>>>
>>>> I found a (non-myth) systemd system. On it I have:
>>>>     $ sudo systemctl | grep LSB
>>>>       cgroupfs-mount.service
>>>>                                           loaded active exited    LSB: Set
>>>> up cgroupfs mounts.
>>>>       cpufrequtils.service
>>>>                                           loaded active exited    LSB: set
>>>> CPUFreq kernel parameters
>>>>     ? docker.service
>>>>                                           loaded failed failed    LSB:
>>>> Create lightweight, portable, self-sufficient containers.
>>>>
>>>> I can examine the failed service with (sudo or you don't get logs, just
>>>> the info):
>>>>
>>>>     $ sudo systemctl status docker.service
>>>>     ? docker.service - LSB: Create lightweight, portable, self-sufficient
>>>> containers.
>>>>        Loaded: loaded (/etc/init.d/docker; generated; vendor preset:
>>>> enabled)
>>>>        Active: failed (Result: exit-code) since Sun 2017-06-11 13:27:42
>>>> BST; 1 months 15 days ago
>>>>          Docs: man:systemd-sysv-generator(8)
>>>>       Process: 1501 ExecStart=/etc/init.d/docker start (code=exited,
>>>> status=1/FAILURE)
>>>>
>>>> Jun 11 13:27:41 dagon systemd[1]: Starting LSB: Create lightweight,
>>>> portable, self-sufficient containers....
>>>> Jun 11 13:27:42 dagon docker[1501]: /usr/bin/docker not present or not
>>>> executable ... failed!
>>>> Jun 11 13:27:42 dagon systemd[1]: docker.service: Control process exited,
>>>> code=exited status=1
>>>> Jun 11 13:27:42 dagon systemd[1]: Failed to start LSB: Create
>>>> lightweight, portable, self-sufficient containers..
>>>> Jun 11 13:27:42 dagon systemd[1]: docker.service: Unit entered failed
>>>> state.
>>>> Jun 11 13:27:42 dagon systemd[1]: docker.service: Failed with result
>>>> 'exit-code'.
>>>>
>>>> As you can see it is using an automatically generated unit file which
>>>> is calling the LSB/sysvinit script (which is actually stale because
>>>> docker isn't installed on this machine).
>>>>
>>>> I would expect you would find something similar based on
>>>> /etc/init.d/mythtv-backend on your system, and probably some sort of
>>>> error message.
>>>>
>>>> Yes, and that's what I did find, that systemd generates a temporary
>>> .service file.
>>>
>>> Trouble is, the log lies:
>>>
>>> root at jade:/home/micheal# systemctl status mythtv-backend
>>> ? mythtv-backend.service - LSB: Start/Stop the MythTV server.
>>>    Loaded: loaded (/etc/init.d/mythtv-backend; generated; vendor preset:
>>> enabled)
>>>    Active: active (exited) since Thu 2017-07-27 15:42:01 BST; 5h 24min ago
>>>      Docs: man:systemd-sysv-generator(8)
>>>     Tasks: 0 (limit: 4915)
>>>    CGroup: /system.slice/mythtv-backend.service
>>>
>>> Jul 27 15:41:56 jade systemd[1]: Starting LSB: Start/Stop the MythTV
>>> server....
>>> Jul 27 15:42:01 jade mythtv-backend[706]: Starting MythTV server:
>>> mythbackend .
>>> Jul 27 15:42:01 jade systemd[1]: Started LSB: Start/Stop the MythTV
>>> server..
>>> root at jade:/home/micheal#
>>>
>>> Unfortunately, 15:42 is the time I shut down the working system before I
>>> redid the database. Apart from the time I ran it manually, all attempts to
>>> start or restart mythtv-backend produce exactly nothing. NO activity I did
>>> afterwards appears to exist in the logs, such as I could figure out of them.
>>
>>
>> Just a quick note - I am sure you have tried, but I should mention it.  If
>> you try to stop a service with systemd (systemctl) that was not started
>> with systemctl, systemd will silently not stop it for you.  If mythbackend
>> is not running, systemd should start it though (in a perfect world where
>> units exist, etc)..
>>
>> Just tossing that out in case you already had it running and tried to stop
>> it with systemd.
>
> Actually, the whole systemd support for System V init scripts is buggy
> and very difficult to work with.  Debugging an init script under
> systemd requires using workarounds that make life difficult.  It is
> much better to install a proper .service file and use systemd as it is
> meant to be used.  Init scripts often just silently fail to start,
> stop or anything else they are supposed to do when used with systemd
> if something goes wrong.
>
> So, if there is no /lib/systemd/system .service file installed by your
> packages, then you should install one yourself manually to
> /etc/systemd/system and remove the /etc/init.d/ script (by renaming it
> if you want to keep it around for reference - add .save to the end of
> the name).  Then run systemctl daemon-reload and try using the new
> .service file.
>
> This is what Mythbuntu uses for /lib/systemd/system/mythbackend.conf:
>
> [Unit]
> Description=MythTV Backend
> Documentation=https://www.mythtv.org/wiki/Mythbackend
> After=mysql.service network.target
>
> [Service]
> User=mythtv
> EnvironmentFile=-/etc/mythtv/additional.args
> ExecStart=/usr/bin/mythbackend --quiet --syslog local7
> $ADDITIONAL_ARGS
> StartLimitBurst=10
> StartLimitInterval=10m
> Restart=on-failure
> RestartSec=1
>
> [Install]
> WantedBy=multi-user.target
>
> That works as long as you are not using external networking with
> mythbackend, such as network tuners or external frontends.  If you are
> using external networking, then this should work, as long as you are
> using Network Manager for your networking:
>
> [Unit]
> Description=MythTV Backend
> Documentation=https://www.mythtv.org/wiki/Mythbackend
> Wants=NetworkManager-wait-online.service
> After=mysql.service network.target NetworkManager-wait-online.service
>
> [Service]
> User=mythtv
> EnvironmentFile=-/etc/mythtv/additional.args
> ExecStart=/usr/bin/mythbackend --quiet --syslog local7
> $ADDITIONAL_ARGS
> StartLimitBurst=10
> StartLimitInterval=10m
> Restart=on-failure
> RestartSec=1
>
> [Install]
> WantedBy=multi-user.target
>
> With this .service file, in your /etc/mythtv directory you can put a
> file additional.args if you need to add things to the mythbackend
> command line.  Mine looks like this:
>
> #ADDITIONAL_ARGS=-v all --loglevel debug
> ADDITIONAL_ARGS=-v record,dvbcam
>
> The .conf files need to be set to chown root:root and chmod
> u=rw,g=r,o=r.
>
> I do not know if the NetworkManager-wait-online.service is enabled by
> default in Debian, so you should also do:
>
> systemctl enable NetworkManager-wait-online.service
>
> to make sure it is.
>
> I find that typing "systemctl" and "journalctl" all the time is a big
> pain, so this is what I have in my /root/.bash_aliases file now:
>
> alias sc='systemctl'
> alias jc='journalctl'
> alias sco='systemctl stop'
> alias scs='systemctl start'
> alias scr='systemctl restart'
> alias scst='systemctl status'
>
Thanks for the above. I'm out most of today so will be trying some of these suggestions out tonight 
or more likely tomorrow.

I'm not sure I like the idea of having NetworkManager around -- in the past it has routinely dropped 
connections after <random> amount of time, and why would you need it on a headless server anyway? 
/etc/network/interfaces is easy enough to configure, especially with DHCP.

I went off systemd when I discovered that they were storing executables under /lib. Standards, anyone?

-- 

Mike Perkins