Running LMS 7.7.1 svn code as a service on Fedora 15/16

[gharris999]

Attached are a couple of scripts that will allow you to install the LMS svn code as a service on Fedora 15 or 16. This install does away with the /etc/init.d/squeezeboxserver script and, instead, uses a systemd service unit file for defining and starting the service.

Note: you may need to install a CPAN module or two to get the service running. The zipfile contains a utility script so that you can more easily debug missing or incompatible modules. In order to get the latest LMS svn code running on my Fedora 15 box, I needed to install cpan CGI:Cookie. You can also follow the instructions here: http://forums.slimdevices.com/showthread.php?t=88250 for building all the CPAN modules.

[gharris999]

OK, I've updated the scripts in an attempt to fix permissions problems.

Basically, I'm finding that there are a whole host of permissions problems depending on how the unit file starts sbs/lms. If the unit file starts sbs as root, passing --user and --group args, then the service has problems creating various elements in the lib directory. On the other hand, if the unit file uses the User= and Group= exec elements, then the service can't write to its pidfile.

The work-around / kludge used in these new scripts is to create the pidfile in /var/lib/lms.

Also: the service account now correctly gets added with a UID <500.

[gharris999]

OK, final tweak: now using systemd-tmpfiles to create /var/run/lms with the correct permissions. The pid file now gets located the "right" place.

[JackOfAll]

Just a friendly heads-up......

Not quite sure why you are sending SIGKILL to the server in the logrotate script after the files are processed. Sending USR1 to the server is all that is required to re-init logging after the rotate rather than killing and having the server restarted by systemd. Not that what you intend will happen anyway looking for the pid of slimserver.pl!

[gharris999]

Just a friendly heads-up......

Not quite sure why you are sending SIGKILL to the server in the logrotate script after the files are processed. Sending USR1 to the server is all that is required to re-init logging after the rotate rather than killing and having the server restarted by systemd. Not that what you intend will happen anyway looking for the pid of slimserver.pl!

I think I settled on SIGKILL via trial and error. I'm willing to experiment some more and try to incorporate anything you suggest. Please feel free to post more fixes or improvements here.

Re pid of slimserver.pl: these scripts are for running the svn code as a service...so pgrep will see slimserver.pl, unlike with the rpm installation. I do have this right, don't I? If there's something I'm not understanding here, please enlighten me.

What is your sense? Is systemd the face of the future? Or is that only going to happen over Canonical's dead body?

[JackOfAll]

Pretty sure that USR1 is all that is needed for the perl logging code to re-open the server logfile after the rotate.

pid of slimserver.pl..... Ah, OK. It's squeezeboxserver.pl in the rpm and that's what I'm running.

The future of systemd..... I've not really been following any other distributions to see whether they are adopting it. The fact that services are started in parallel does improve the startup time taken to get to a gui login, which has got to be the main advantage from a "normal" user perspective.

[gharris999]

@JackOfAll (or anyone else):

On debian systems, the lms|sbs|squeezeboxserver process has a parent "safe" process which is a bash script. On those systems, I think the log rotate script is sending USR1 to that process rather than to the perl process. Does this matter? Or should I tweak the log rotate script so that pgrep returns the perl process?

So..rather than the postrotate command being:

/bin/kill -USR1 \`pgrep lms -n 2>/dev/null\` 2>/dev/null || :

..instead use something like:

/bin/kill -USR1 \`pgrep -f 'perl.*slimserver.pl' -n 2>/dev/null\` 2>/dev/null || :

..Yes?