systemd service file for LMS

[scytale]

These days, Debian, and the Debian package builder, has support for different init systems "built-in". So it should be equally straightforward to use the package builder's provided method instead a custom post-install script.

Is there a reason why you don't suggest this approach ?

Nope I wasn't aware that that facility had been added

I don't regularly maintain Debian packages, so any insight welcome.

It's been several years since I worked with deb building myself.

However the lms package looks quite trivial, and at a glance it looks like everything is handled by the buildme.sh script

Which is what I was planning to do, for Debian only, after testing the service file that I originally suggested for a suitable period of time.

Well, three months have passed and I have not experienced any issue on the few occasions I have started/stopped LMS in that time, and no-one else has reported any. I suppose some people may have tested .

So, I guess the time has come. I'll await @scytales's input.

Why don't you open a PR with what you've got (even if it's just the systemd unit file and nothing else) and we'll take it from there.

[mrw]

- submit pull request ;-)

https://github.com/Logitech/slimserver-platforms/pull/18

[scytale]

Further note:

Just updated from 8.1.1 to latest 8.2.0 on my RPi running Ubuntu 20.10 x86_64 aarch64.

It transitioned seamlessly from using the init script to using the systemd unit file.

(Plus I can now drop the custom perl 8.30 support I'd never quite round to opening a PR for)

[Johan S]

systemd unit for RPM distribution

The Fedora init script is overly complex because it was written so that a single rpm file could support multiple rpm-based OS's. I *think* that a systemd implementation would be much simpler, but I'm not really knowledgeable enough about systemd to say that with any conviction. Hopefully a Fedora (etc) user with some systemd experience can chime in.

Hi,

I had a first look at adding a systemd unit for the logitechmediaserver RPM distribution. Creating the unit file is indeed not very difficult, the one for Debian presented here could be used with only some minor changes.

The attached ZIP-archive contains example, it should be dropped in /usr/lib/systemd/system. Any local amendments should be dropped in /etc/systemd/system/squeezeboxserver.service or /etc/systemd/system/squeezeboxserver.servic.d/*.conf. Of course systemctl daemon-reload must be run. Compared with the Debian systemd unit file I have removed a few things that anyway corresponded to the systemd default settings.

The second file in the archive is an example of how /etc/sysconfig/squeezeboxserver could look like.

My main concern lies with the /etc/sysconfig/squeezeboxserver file (corresponds to the Debian /etc/default/logitechmediaserver) in the RPM distribution:

• it is used for more settings than on Debian
• it uses nested variables (SQUEEZEBOX_ARGS), which systemd will not be able to pick up properly.
• if the values for the LOG_DIR, CFG_DIR and CACHE_DIR are changed, then settings made to SELINUX in the RPM post install script are invalidated and must be manually re-done (but maybe a person using SELINUX is aware of this anyway).

Just to illustrate, here is an example of the the current /etc/sysconfig/squeezeboxserver

# Edit this to suit your setup
SQUEEZEBOX_USER="squeezeboxserver"
SQUEEZEBOX_HOME="/usr/libexec"
SQUEEZEBOX_CFG_DIR="/var/lib/squeezeboxserver/prefs"
SQUEEZEBOX_LOG_DIR="/var/log/squeezeboxserver"
SQUEEZEBOX_CACHE_DIR="/var/lib/squeezeboxserver/cache"
SQUEEZEBOX_CHARSET="utf8"
SQUEEZEBOX_ARGS="--daemon --prefsdir=$SQUEEZEBOX_CFG_DIR --logdir=$SQUEEZEBOX_LOG_DIR --cachedir=$SQUEEZEBOX_CACHE_DIR --charset=$SQUEEZEBOX_CHARSET"

Furthermore the post install script in the RPM distribution would need to be updated with logic to handle SYSV vs. systemd systems and with logic to handle changes to /etc/sysconfig/squeezeboxserver.

I would appreciate your thoughts on:

• the unit file itself
• what should be done with the /etc/sysconfig/squeezeboxserver file and how much effort should be made to detect changes and incorporate these change in the set-up for systemd. In the most far reaching scenario this file could be removed and replaced with drop-in files in /etc/systemd/system/squeezeboxserver.service.d

[Johan S]

Files needed for RPM to support systemd unit

Hi,

The attached gzip contains 5 files needed to build an RPM supporting systemd unit files.

- The unit file itself squeezeboxserver.service
- A new version of the /etc/sysconfig/squeezeboxserver (squeezeboxserver.config)
- A new file README.systemd with some explanations about the migration from SYSV to systemd
- An amended squeezeboxserver.spec
- An amended buildme.pl (just added the two new files to be copied to the RPM source directory).

In addition to the support of systemd, I also fixed the issues with the missing symbolic link to

- /usr/lib/perl5/site_perl/Slim for SUSE distributions
- /usr/lib64/perl5/vendor_perl/Slim for RedHat based x86_64 distributions

Please let me know if I need to deliver the files in another way.

I have tested this on CentOS and SUSE. I don't expect RHEL or Fedora to behave different compared to CentOS. I would appreciate feedback and if someone could do some tests as well.

Regards, Johan


new-platform-redhat.tar.gz

[mherger]

systemd service file for LMS

> Please let me know if I need to deliver the files in another way.

A pull request on github would be perfect.

https://github.com/Logitech/slimserver-platforms/pulls

Thanks for your effort anyway!

[Johan S]

> Please let me know if I need to deliver the files in another way.

A pull request on github would be perfect.

https://github.com/Logitech/slimserver-platforms/pulls

Thanks for your effort anyway!

I have created https://github.com/Logitech/slimserv...tforms/pull/22.
I am sorry for the non-descript title. git is not my strong suit.
I hope I got it right.

Regards, Johan

[Johan S]

Some amendments to the RPM spec file.

Hi,

After seeing this thread, I realised that if a hard link or a copy of the squeezeboxserver perl libraries have been made instead of a symbolic link, then an update of the squeezeboxserver will not succeed as the new version will use old perl libraries, as the post install script will not be able to create the symbolic link over the existing directory.

I have added a test in the post install script to see if the directory/file Slim exists in /usr/lib64/perl5/vendor_perl (RedHat) or /usr/lib/perl5/site_perl (SUSE) and if it is a symbolic link. If the file/directory exists and is not a symbolic link, then it will be removed (a backup copy will be created) and a symbolic link will be created instead pointing to the the directory /usr/lib/perl5/vendor_perl/Slim installed by the RPM package.

I have also

- added a few re-directs of STDOUT and STDERR in the post install script to prevent these to be printed on the screen during install.
- corrected an error in the README.systemd.

Here is my new pull request. I hope I got it right this time.

https://github.com/Logitech/slimserver-platforms/pull/23

Regards, Johan

[Johan S]

Some amendments to the RPM spec file.

Some additional information...

The squeezebox server RPM package drops the PERL libraries in /usr/lib/perl5/vendor_perl.

64bit CentOS (and I assume RedHat and Fedora) have the following locations in the PERL @INC variable.

/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

For CentOS/RedHat/Fedora my amended version of the RPM post install script will check in /usr/lib64/perl5/vendor_perl if any Slim directory/hard link/symbolic link exists. If a directory or a hard link Slim exists in that directory, then it will be re-named to Slim.rpmsave and a symbolic link to /usr/lib/perl5/vendor_perl/Slim will be created instead.

PLEASE NOTE: If a hard link or a copy of an old version of /usr/lib64/perl5/vendor_perl exists in /usr/local/lib64/perl5 and/or /usr/local/share/perl5, then that version of the Slim PERL modules will be used.

One could of course search these locations too, for hard links or copies of Slim, but I am not sure that this is desirable. If anyone has good arguments to search these locations too to remove unwanted copies of Slim, then it could of course be changed.

Similarly, SUSE has the following locations in @INC

/usr/lib/perl5/site_perl/5.26.1/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.26.1
/usr/lib/perl5/vendor_perl/5.26.1/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.26.1
/usr/lib/perl5/5.26.1/x86_64-linux-thread-multi
/usr/lib/perl5/5.26.1
/usr/lib/perl5/site_perl

The squeezebox server RPM package has always attempted to create a symbolic link to /usr/lib/perl5/vendor_perl from /usr/lib/perl5/site_perl/Slim (although this functionality has been broken since some years). I have added a check for hard links/directories in this location to remove them if needed and put a symbolic link in their place. If someone has added a hard link to or a copy of the perl modules in any of the other locations in @INC, then that copy will be preferred and the squeezebox server installation will most likely be broken.