systemd service file for LMS

[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]

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?

[jvromans@squirrel.nl]

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

[Shart]

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

Thanks. I tried various methods to get it to run. Without any script changes it just restarts over and over so I thought I'd see if anyone had any idea or suggestions. I know it's to do with perl. I got it to run via docker for now but not what I'd prefer.

[mherger]

> 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

This most likely has nothing to do with the startup script. It's rather
lack of binary support your system's Perl. What would "perl -v" say?

--

Michael

[mrw]

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.

Ubuntu 20.04 ships with Perl 5.30. As yet, it seems only x86_64 binaries are available for v5.30. So, LMS will fail to start on your arm64 system.

Is arm64 the same as aarch64 ?

[Mark Miksis]

Ubuntu 20.04 ships with Perl 5.30. As yet, it seems only x86_64 binaries are available for v5.30. So, LMS will fail to start on your arm64 system.

I assume you can still just follow the instructions to build the required perl modules and then use your service file for systemd?

[mrw]

I assume you can still just follow the instructions to build the required perl modules and then use your service file for systemd?

Yes, the service file is agnostic in that regard.

As an aside, I find the following yields a useful diagnostic system log extract (in reverse order).

sudo journalctl -r -u logitechmediaserver

The squeezeboxserver_safe start up script obscures some of the start up logging, so another benefit of this service file.

[Mark Miksis]

--d_startup is often helpful