[mythtv-users] mythtv-status init

[Stephan Seitz]

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
>> exited
>> 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 
cli.

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:
noupdate
	Don’t run the scripts in /etc/update-motd.d to refresh the motd 
	file.

osgiliath:/etc/pam.d# ls -l /etc/update-motd.d/
insgesamt 4
-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
>again.

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 
broken.

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 
for /etc/update-motd.d.

>> 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!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5140 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20180629/a5c2c2a1/attachment.bin>