[mythtv-users] mythtv-status init
stse+mythtv at fsing.rootsland.net
Fri Jun 29 13:23:23 UTC 2018
On Do, Jun 28, 2018 at 11:58:19 +1200, Andrew Ruthven wrote:
>On Tue, 2018-06-26 at 11:15 +0200, Jeff wrote:
>> Nearly every time my myth machine starts, I get emails with the
>> following subject:
>> Cron <root at xxx> [ -x /etc/init.d/mythtv-status ] &&
>> /etc/init.d/mythtv-status reload > /dev/null
>> and content:
>> Job for mythtv-status.service failed because the control process
>> with error code. See "systemctl status mythtv-status.service" and
>> "journalctl -xe" for details.
>/me shacks his fist at systemd
I’m not sure that the problem is systemd this time. I’m using sysvinit,
and while I don’t get a mail, I get an error at boot time as well.
Interestingly it works later from CLI (but see below).
I’m using Debian testing, and updating the motd isn’t working anymore
here as well from the cronjob (or maybe one should say, the results
aren’t printed anymore).
I don’t know when it started, because I don’t need motd updates, only the
mythtv-status creates or updates the file /run/motd.dynamic. The PAM
configuration for motd is (here from login):
# Prints the message of the day upon successful login.
# (Replaces the `MOTD_FILE’ option in login.defs)
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
The manpage of pam_motd says:
Don’t run the scripts in /etc/update-motd.d to refresh the motd
osgiliath:/etc/pam.d# ls -l /etc/update-motd.d/
-rwxr-xr-x 1 root root 23 Apr 4 2017 10-uname
So motd.dynamic gets overwriten by PAM with the only script available
(10-uname). Since mythtv-status doesn’t have a script in this directory
but writes directly to motd.dynamic it is now quite useless.
>> I'm guessing that because this is a pre-systemd init script, systemd
>> is not always running it before mythbackend is up, because systemd
>> doesn't know that the mythtv-status depends on mythbackend.
>That is quite possibly right. Probably time for me to look into that
The init script has
# Should-Start: $named mythtv-backend motd
osgiliath:/etc/pam.d# ls -l /etc/rc2.d/ | grep myth
lrwxrwxrwx 1 root root 24 Okt 18 2016 S06mythtv-backend -> ../init.d/mythtv-backend
lrwxrwxrwx 1 root root 23 Okt 18 2016 S07mythtv-status -> ../init.d/mythtv-status
So the backend is started first, but since it takes some time to start,
the init script for mythtv-status fails.
At boot time mythtv-status only tries to update the motd. And it has
a cron job that tries the same, so you could remove mythtv-status from
the boot sequence and rely on the cron job. But see above, here it is
You could deactivate the script in /etc/default/mythtv-status, but
I don’t know if systemd honors the settings in this file.
So if you want to work on mythtv-status again I would remove the init
script and the cron job for Debian systems. Then I would write a script
>> then I'm not going to break anything that isn't broken, and the
>> command-line functionality of mythtv-status will still work?
>You are correct.
Yes, the CLI is working as expected.
Shade and sweet water!
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5140 bytes
Desc: not available
More information about the mythtv-users