Systemd mythbackend Configuration
Some newer Linux distributions (including Ubuntu 15.04 onwards) replace the traditional LSB init script startup management process with a program called systemd, which does things differently; here are some notes on how to make MythTV play nicely with systemd. A cheatsheet from the traditional init scripts to systemd is available on the Fedora wiki pages.
Note that much of the example startup code that follows is based on the rpmfusion packaging of MythTV by Richard Shaw.
Save the configuration file below in
Changes to files in /lib/systemd/system will be over-written when updated.
To enable the backend to start at the next boot, issue the command 'systemctl enable mythbackend.service'. To start the backend immediately, issue the command 'systemctl start mythbackend.service'.
If you specify a log file, all logging will be to that file. If you specify a logpath each program will write to distinctly named files: much better for debugging. Loglevel determines what is logged. Log messages at lower levels will be discarded: In descending order: emerg, alert, crit, err, warning, notice, info, debug. Defaults to info.
Another example for an ubuntu configuration
Please check this file is suitable for your requirements and edit where necessary.
Save the first configuration file below in
/etc/systemd/system and the
If you have been using mythbuntu check that there are no mythtv-backend.service files
here or in
This isolates all configuration related to the startup of mythbackend within systemd configuration files.
It can also be used on other distibutions using systemd. But check on the locations of systemd unit files.
Allow the backend to restart on failure
Sometimes the backend will coredump in the middle of a firewire recording, for example. Or it just gets tired after a while and coredumps. Restarting it can clear things up, and pick up a recording where it left off (minus restart time). If you're there to restart it. SystemD can restart the backend with a simple setting and manual backend restart.
Delay starting the backend until tuners have initialized
Some tuners take a long time to initialize (typically, firmware loading) and may therefore not yet be available when the backend starts. Since the backend checks for the presence of tuners upon startup, tuner initialization needs to be completed before the backend is started.
This can be accomplished by adding additional Wants= and After= stanza to the unit file, but to have systemd create device units, you must first add a rule to the udev rules directory.
With the udev rule tag, systemd will create a device unit at startup that one can add to the [Unit] stanza in the startup. Note that one must use the systemd mangled names (generally /dev/some/thing is mangled into dev-some-thing.device). It is highly recommended that you use udev persistent names rather than base names such as /dev/video0.
From mythtv-users post from Richard Shaw
Systemd has a built-in timeout on device units so that startup will not wait forever for a failed device startup.
There are many options for how to run mythbackend with SystemD but one decision you
make is if you're going to run:
If you use Type=simple (which is my recommendation) then you *CANNOT* use the "--daemon" option because SystemD is not expecting the daemon to fork!!!
If you use Type=forking then you *MUST* use the "--daemon" option as well as specify a PID file, "--pidfile" in ExecStart *AND* you must set the PIDFile= systemd option so it knows where to find the PID file.
Someone please fix the wiki!
Alternatively:- Forum Link "sudo systemctl edit mythtv-backend.service" and then add the following two lines:
Delay starting the backend until network has initialized
The addition of pingnetwork.service to both a "Wants=" and "After=" line in the [Unit] section of mythbackend.service should greatly improve/eliminate mythfrontend clients failure to connect to the server. As user "root", enable the service: systemctl enable pingnetwork.service Reference : mythtv ticket #11160 Fedora 18 rpms: NetworkManager-0.9.7.0-12.git20121004 : systemd-197-1 If remote clients/mythfrontend fail to connect to mythbackend, on the machine hosting mythbackend, examine /var/log/boot.log for a failed "Network Manager Wait Online" service, or execute "systemctl status NetworkManager-wait-online.service" and look for failure due to timeout. cp -iv /usr/lib/systemd/system/NetworkManager-wait-online.service \ /etc/systemd/system/ # Edit /etc/systemd/system/NetworkManager-wait-online.service to extend the # timeout value. Doubling the default to 60 is suggested. vi /etc/systemd/system/NetworkManager-wait-online.service ExecStart=/usr/bin/nm-online -q --timeout=60 Reboot and check boot.log or use systemctl command above to check for the successful execution of NetworkManager-wait-online.service. Increase the timeout value if necessary and reboot. Below is a status report of success: systemctl status NetworkManager-wait-online.service NetworkManager-wait-online.service - Network Manager Wait Online Loaded: loaded (/etc/systemd/system/NetworkManager-wait-online.service; enabled) Active: inactive (dead) since Tue 2013-02-02 15:31:44 EST; 2min 16s ago Process: 827 ExecStart=/usr/bin/nm-online -q --timeout=60 (code=exited, status=0/SUCCESS) Feb 02 15:31:11 stumble systemd: Starting Network Manager Wait Online... Feb 02 15:31:44 stumble systemd: Started Network Manager Wait Online.
Quickly terminate mythbackend
If “systemctl stop mythbackend” takes 90 seconds to complete, the mythbackend process is being shut down uncleanly. One could add “TimeoutStopSec=5” to the [Service] section of the mythbackend.service file, but this would still kill mythbackend abruptly. One reason for smoothly shutting down mythbackend would be to enable use of a program profiler such as the GNU profiling tool gprof. One solution: 1) add “--pidfile /var/log/mythtv/mythbackend.pid” to your ExecStart line in mythbackend.service (if necessary). 2) Change/Add the ExecStop line in the same file's [Service] section to: ExecStop=/usr/local/bin/mythbackendstop 3) Create /usr/local/bin/mythbackendstop. Make the script executable. #!/bin/bash # Custom stop script to execute `kill -15` twice (which mythbackend # apparently needs to exit cleanly) KILLIT=`/usr/bin/cat /var/log/mythtv/mythbackend.pid` /usr/bin/kill -15 $KILLIT;/usr/bin/sleep 2;/usr/bin/kill -15 $KILLIT Once properly set up, “systemctl stop mythbackend” will terminate mythbackend in just a few seconds.
Logging to systemd journalMythbackend can be configured to log to the systemd journal. To do this add the parameter
--systemd-journalto the startup command line. Mythbackend sets the SYSLOG_IDENTIFIER to the name of the program (by default "mythbackend"). So the log can be easily viewed by the command.