systemd service file for LMS

[mrw]

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

Thanks Johan! Merged in 8.2 - give it all a try.

[mrw]

systemd service file for LMS

Following some recent comments in this forum, I have had a go at constructing a systemd unit service file for use on Debian based systems. It is attached to this post.

If it, or something like it, passes muster, it could be incorporated into the Debian installer package so as to co-exist peacefully with the existing SysV init script. That will take a little more research.

Points:

• squeezeboxserver_safe goes, and LMS is started directly by systemd. No 'supervisor', if it fails it stops.
• Supports setting start up options by using /etc/default/logitechmediaserver, similar to the existing SysV init script.
• But LMS user is hardcoded to 'squeezeboxserver'.
• Checks that /var/log/squeezeboxserver exists and is writeable, and creates it if not.
  (Good for systems with /var/log mounted as temporary file system).
  (But only on modern versions of systemd).
• Service reload sends 'HUP' to LMS, initiating some kind of LMS reinitialization.
  This may not be useful, I've never used it.
• Addresses issue whereby LMS may start 'too early', before network connections are configured.
  In systemd speak, by including an After=network-online.target stanza in the service file.
  It is left to the user to configure his system in a manner that gives appropriate meaning to the 'network-online.target'.

I've left rather too many notes in the file, but they record my thoughts.

I've tested it on Debian 8 (Jessie, systemd 215), Debian 9 (Stretch, systemd 232), and Debian 10 (Buster, systemd 241), and all seems to work as expected. I shall continue to run with it for a few weeks to see if any problems emerge.

To install manually onto an existing system:

• Stop LMS with systemctl stop logitechmediaserver.service
• Install the service file as /etc/systemd/system/logitechmediaserver.service
• Reload systemd configuration with systemctl daemon-reload
• Restart LMS with systemctl start logitechmediaserver.service

Comments welcome.

[[email protected]]

systemd service file for LMS

Good job!

[mherger]

systemd service file for LMS

> Following some recent comments in this forum, I have had a go at
> constructing a systemd unit service file for use on Debian based
> systems. It is attached to this post.

Great, thanks! This has been a topic for a while now.

> If it, or something like it, passes muster, it could be incorporated
> into the Debian installer package so as to co-exist peacefully with the
> existing SysV init script. That will take a little more research.

I'm not a Debian guy. Actually... while I've been using some sort of
Linux for decades, I'm not really a Linux guy, mostly just a user. So...
Are you saying it would be possible to have old and new in parallel? If
so, how would the system decide what to use?

And would we expect this work with Ubuntu and its numerous descendants, too?

--

Michael

[slartibartfast]

Following some recent comments in this forum, I have had a go at constructing a systemd unit service file for use on Debian based systems. It is attached to this post.

If it, or something like it, passes muster, it could be incorporated into the Debian installer package so as to co-exist peacefully with the existing SysV init script. That will take a little more research.

Points:

• squeezeboxserver_safe goes, and LMS is started directly by systemd. No 'supervisor', if it fails it stops.
• Supports setting start up options by using /etc/default/logitechmediaserver, similar to the existing SysV init script.
• But LMS user is hardcoded to 'squeezeboxserver'.
• Checks that /var/log/squeezeboxserver exists and is writeable, and creates it if not.
  (Good for systems with /var/log mounted as temporary file system).
  (But only on modern versions of systemd).
• Service reload sends 'HUP' to LMS, initiating some kind of LMS reinitialization.
  This may not be useful, I've never used it.
• Addresses issue whereby LMS may start 'too early', before network connections are configured.
  In systemd speak, by including an After=network-online.target stanza in the service file.
  It is left to the user to configure his system in a manner that gives appropriate meaning to the 'network-online.target'.

I've left rather too many notes in the file, but they record my thoughts.

I've tested it on Debian 8 (Jessie, systemd 215), Debian 9 (Stretch, systemd 232), and Debian 10 (Buster, systemd 241), and all seems to work as expected. I shall continue to run with it for a few weeks to see if any problems emerge.

To install manually onto an existing system:

• Stop LMS with systemctl stop logitechmediaserver.service
• Install the service file as /etc/systemd/system/logitechmediaserver.service
• Reload systemd configuration with systemctl daemon-reload
• Restart LMS with systemctl start logitechmediaserver.service

Comments welcome.

I run MusicIP on my Pi and LMS startup has to be delayed until after MusicIP has started. At the moment I restart LMS after 30 seconds with a line in rc.local. Would this be possible with the proposed system?

Sent from my Pixel 3a using Tapatalk

[[email protected]]

systemd service file for LMS

> I run MusicIP on my Pi and LMS startup has to be delayed until after
> MusicIP has started. At the moment I restart LMS after 30 seconds with a
> line in rc.local. Would this be possible with the proposed system?

You can add a systemctl service for MusicPI, and have starting LMS depend
on the MusicPI target.

[mrw]

Are you saying it would be possible to have old and new in parallel?

Yes.

how would the system decide what to use?

Nice question ! Can you let me know on what platform/version the Debian build process is currently being run on ? A detailed answer may depend on that, somewhat.

As a flavour, on my Debian 10 (Buster) system, the Debian package builder's generated installation scripts provide that:

• Starting and stopping LMS is undertaken by invoke-rc.d.
  
  Despite its name, on a systemd system it invokes systemd commands to do its work, in place of executing the SysV init script.
  
  invoke-rc.d has, I think, been present on Debian based systems for many years, so it should be OK. The Debian package currently distributed uses this tool, so unless you are aware of any complaints...
  
  It's currently provided by the 'essential' package init-system-helpers, but previously by sysvinit related packages.
  
  
• Enabling/disabling/masking a systemd unit file is undertaken by deb-systemd-helper.
  
  I suspect that its absence may not actually cause any problems, but it remains a subject for research.
  
  
• It requires a very minor change to the existing control and rules files.

Earlier versions of the Debian package builder will have done things a little differently. So I need to research that.

And would we expect this work with Ubuntu and its numerous descendants, too?

Yes. I'd be astonished if Ubuntu departed from Debian in this area, and I'm not seeing any sign of it. There again, I have been astonished on many occasions in the past...

Ultimately we have the ability to put whatever we want into the generated installation scripts. Best avoided, though. I'm not a "Debian guy", either, but I have the time to research right now. Ideally one wants an essentially maintenance free approach.

Best case is that it all just works well enough with the very minor changes to the control and rules files. But we need, I think, to specify a minimum supported build platform. I'm thinking, perhaps, Debian 8 (Jessie), or Ubuntu equivalent. Research required.

Worst case would be that we find ourselves adding the necessary stanzas by hand into the installation scripts, to suit our target audience(s). The snippets would not be extensive, so it is a perfectly do-able approach. But not so "maintenance free", and would require some (perhaps minimal) knowledge of Debian packaging. Experience may dictate that this approach is needed, but I'm hopeful that it won't be.

[mherger]

systemd service file for LMS

>> how would the system decide what to use?
>
> Nice question ! Can you let me know on what platform/version the Debian
> build process is currently being run on ? A detailed answer may depend
> on that, somewhat.

It's a x86_64 (VM) Debian 9.

--

Michael

[mrw]

It's a x86_64 (VM) Debian 9.

Thanks. I have a Debian 9 container available, I'll make sure to check build result on that.

[philchillbill]

I run MusicIP on my Pi and LMS startup has to be delayed until after MusicIP has started. At the moment I restart LMS after 30 seconds with a line in rc.local. Would this be possible with the proposed system?

In the [Service] section, you could add

ExecStartPre=/bin/sleep 30

to cause a 30 second sleep before LMS is started.

A look at the ngrok.service script associated with the MediaServer skill will show many similarities to this script.

[Mark Miksis]

I haven't used Redhat/Fedora/CentOS/etc in a very long time, but I believe they have also moved to systemd. Is there any reason to believe that your work wouldn't also be applicable to the rpm packages?

[mrw]

I haven't used Redhat/Fedora/CentOS/etc in a very long time, but I believe they have also moved to systemd. Is there any reason to believe that your work wouldn't also be applicable to the rpm packages?

I haven't used any of those OS's, and my effort has been very LMS-Debian driven.

I had a quick glance at, I think, the Fedora init script. It did seem to differ quite significantly, and I doubt that my effort could be used as a simple drop in. I think the approach one might take is to build a systemd unit file based on what's going on within the Fedora script. That done, look for the common features, see what might be "merged", and see what is distribution specific.

systemd provides for unit file overrides. So in principle one might end up with a common "upstream" defined unit file, which the distribution then tweaks as necessary by way of override files. (To be found in a ".d" directory by the same name, and with ".conf" suffixes). Whether LMS's historical development would easily allow that approach is another matter.

[Mark Miksis]

I haven't used any of those OS's, and my effort has been very LMS-Debian driven.

I had a quick glance at, I think, the Fedora init script. It did seem to differ quite significantly, and I doubt that my effort could be used as a simple drop in. I think the approach one might take is to build a systemd unit file based on what's going on within the Fedora script. That done, look for the common features, see what might be "merged", and see what is distribution specific.

systemd provides for unit file overrides. So in principle one might end up with a common "upstream" defined unit file, which the distribution then tweaks as necessary by way of override files. (To be found in a ".d" directory by the same name, and with ".conf" suffixes). Whether LMS's historical development would easily allow that approach is another matter.

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.

[Shart]

No LMS Love

Hi -

I tried the service scripy on Raspberry Pi 4 with Ubuntu Server 20.04 arm64 with no luck (latest 8 build). The service fails to start. I do get the Perl error:

DBI EV XML::Parser::Expat HTML::Parser JSON::XS Digest::SHA1 YAML::XS Sub::Name

.

I had no issues getting the service to run on the Desktop version for Pi and PC of Ubuntu which I find odd.

This is in my system log:

Nov 2 17:53:57 ubuntu systemd[1]: logitechmediaserver.service: Succeeded.
Nov 2 17:54:13 ubuntu systemd[1]: Reloading.
Nov 2 17:54:14 ubuntu systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
Nov 2 17:54:16 ubuntu systemd-resolved[1746]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

Nov 2 17:54:24 ubuntu systemd[1]: logitechmediaserver.service: Succeeded.
Nov 2 17:54:48 ubuntu systemd-resolved[1746]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

Checking with: systemctl -r --type service --all, the service is not running nor is it located in processes.


Any suggestions?

[[email protected]]

systemd service file for LMS

On Mon, 2 Nov 2020 18:03:12 +0000, Shart
<Shart.9rq38n (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> I tried the service scripy on Raspberry Pi 4 with Ubuntu Server 20.04
> arm64 with no luck (latest 8 build). The service fails to start. I do
> get the Perl error: > DBI EV XML::Parser::Expat HTML::Parser JSON::XS
> Digest::SHA1 YAML::XS
> > Sub::Name.

This is not related to the systemd service. Maybe your LMS install is
corrupt (or wrong architecture?). This error message typically indicates
that the native libraries do not match.

-- Johan