Remove Sys V Init support from RPM distribution. by JohanSaaw · Pull Request #106 · LMS-Community/slimserver-platforms

JohanSaaw · 2026-02-24T13:42:25Z

Fedora. RedHat and SUSE moved from Sys V Init to systemd in 2011 (Fedora
v. 15) and 2014 (RHEL7 and openSUSE/SLES 12) respectively.

The LMS RPM package has supported Sys V Init and systemd in parallel since
v. 8.2. The RPM package installs the systemd support by default if the OS
use systemd (users can of course change this after installation, but why
would they?).

I think it is now time to remove the support for Sys V Init. This mainly
means removing the Sys V Init script and some logic in the RPM spec file.

The file /etc/sysconfig/lyrionmusicserver was used to pass basic start-up
configuration to the Sys V Init script. This file has now been replaced
with a stub file pointing to a file explaining how to change the start-up
configuration using systemd drop in files for the systemd unit.

Further changes:

a small fix to the logrotate configuration.
added a dependency on systemd in the RPM spec file (%systemd_requires)

As all the RPM based distributions use systemd now, and have done it for an extended period of time, it is no longer necessary for the Lyrion RPM package to support Sys V Init.

Updated and improved information on how to use systemd drop in files to amend/change the start-up parameters of Lyrion Music Server

The file /etc/sysconfig/lyrionmusicserver was used to configure start-up parameters for the Lyrion Music Server when it was controlled by Sys V Init. The file can also be used by systemd, but it fits very badly in the concept of systemd. It is better not to use it at all. The file is thus replaced by a stub file with some information and a pointer to the README.systemd file.

The use of pgrep in the postrotate section was wrong

The Init script file has been removed. Logic for migrating non-standard Sys V Init configuration to systemd has been removed, The systemd unit file is now properly installed using standard RPM techniques Added dependency on system (%systemd_requires) as the package provides a unit file.

The Sys V Init is outdated. Removed the parallel support of Sys V init. Now only supporting systemd.

Some further small teaks to the explanations to make it more readable.

Made some changes to improve the explanations on how to use drop in files for the systemd unit file.

Removed references to Sys V Init in the README file.

JohanSaaw · 2026-02-24T13:44:41Z

Hi,

I have a further question. The RPM sepc file has a require statement for PERL to be v 5.10 or higher. I have seen the change to remove PERL binaries for versions 5.20 and earlier.

Should I also bump the spec file require statement to require PERL version 5.22 or higher?

Regards, Johan

michaelherger

Thanks for this PR! As you know I'm no expert in this area...

@mavit - would you mind sharing your review thoughts of this suggested change?

michaelherger · 2026-02-24T19:09:51Z

redhat/lyrionmusicserver.logrotate

+        # send USR1 to lyriuonmusicserver PID to reset logging
+        /bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 || true


typo in comment, change on purpose in the process name?

Hi,

Sorry for the typo. I'll fix that straight away.

The change in the process name is the main error that I fixed in that file. The pgrep command uses the string in the /proc/[pid]/stat file to find the PID. In that file only the first 15 characters of the command is used. If you pass longer strings to pgrep it will not find anything, unless you pass the string with the -f flag (and I have seen that this can lead to other unwanted side effects).

If you look at the logrotate file in the Debian package you will see the same there. They have also shortened squeezeboxserver.

But it is only good if someone else has a look at this too. Also maybe at the question about the required version of PERL in the RPM spec file.

Regards, Johan

Fixed a silly typo in a comment.

mavit · 2026-02-26T13:53:37Z

Should I also bump the spec file require statement to require PERL version 5.22 or higher?

Seems sensible. We should probably also mention the maximum supported version, so:

Requires: (perl >= 5.22 and perl < 5.43)

For maximum accuracy, we could even:

Requires: (perl(:MODULE_COMPAT_5.22.0) or \
           perl(:MODULE_COMPAT_5.24.0) or \
           perl(:MODULE_COMPAT_5.26.0) or \
           perl(:MODULE_COMPAT_5.28.0) or \
           perl(:MODULE_COMPAT_5.30.0) or \
           perl(:MODULE_COMPAT_5.32.0) or \
           perl(:MODULE_COMPAT_5.34.0) or \
           perl(:MODULE_COMPAT_5.36.0) or \
           perl(:MODULE_COMPAT_5.38.0) or \
           perl(:MODULE_COMPAT_5.40.0) or \
           perl(:MODULE_COMPAT_5.42.0))

mavit · 2026-02-26T13:14:46Z

redhat/lyrionmusicserver.logrotate

    postrotate
-        /bin/kill -USR1 `pgrep lyrionmusicserver >/dev/null 2>&1` >/dev/null 2>&1 || true
+        # send USR1 to lyrionmusicserver PID to reset logging
+        /bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 || true


Now that we know that we have systemd, how about the following, to deliver the signal without guessing the process from its name?

Suggested change

/bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 || true

systemctl --kill-whom=main --signal=USR1 kill lyrionmusicserver.service

@mavit ,

Thanks for this suggestion. I was looking at this possibility too, but in the end decided against it, mostly because I did not want to change too much. But as you think this is better, then I'll add this. I would just like to do one small change and that is to use the full path to systemctl:

/usr/bin/systemctl --kill-whom=main --signal=USR1 kill lyrionmusicserver.service

Do you have any objections?

Regards, Johan

Looks good to me.

mavit · 2026-02-26T13:25:41Z

redhat/lyrionmusicserver.spec


 # FHS compatible directory structure
-mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/init.d
+mkdir -p $RPM_BUILDROOT%{_unitdir}


We need the following to ensure we have the %{_unitdir} macro:

BuildRequires: systemd-rpm-macros

https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging_filesystem

@mavit,

OK, will do this. I guess I was lucky that it worked on my server without that macro. I will let you all know when I have implemented and tested this.

Regards, Johan

mavit · 2026-02-26T14:03:29Z

redhat/lyrionmusicserver.spec

+/usr/bin/systemctl enable  %{shortname}.service >/dev/null 2>&1 || :
+/usr/bin/systemctl restart %{shortname}.service >/dev/null 2>&1 || :


The idea of unconditionally enabling the service when the package is upgraded, even if the user has previously disabled it, makes me uneasy. Could we use presets and scriptlets instead?

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd

@mavit,

Yes I know this is strange, but it has always been like this, even before systemd support was introduced. The RPM scripts enabled and started the service. Please allow me some time to read up on the guide lines, and then I'll update the respective scripts.

Regards, Johan

JohanSaaw added 10 commits February 24, 2026 12:19

Delete the Sys V init file for RHEL and SUSE based distibutions.

fe506cb

As all the RPM based distributions use systemd now, and have done it for an extended period of time, it is no longer necessary for the Lyrion RPM package to support Sys V Init.

Updated infrmation on how to use unit drop in files for Lyrion

a6d5bfb

Updated and improved information on how to use systemd drop in files to amend/change the start-up parameters of Lyrion Music Server

Fix an error in the logrotate config.

541cafb

The use of pgrep in the postrotate section was wrong

Removal of Sys V Init support

8e4d931

The Sys V Init is outdated. Removed the parallel support of Sys V init. Now only supporting systemd.

Fix small error in logrtate config

026208e

Remove Sys V Init support

13d7116

Some further small teaks to the explanations to make it more readable.

Remove Sys V Init support

56d277e

Made some changes to improve the explanations on how to use drop in files for the systemd unit file.

Remove Sys V Init support

a320f9e

Removed references to Sys V Init in the README file.

michaelherger reviewed Feb 24, 2026

View reviewed changes

Fix error in logrotate.conf

1dadef3

Fixed a silly typo in a comment.

mavit suggested changes Feb 26, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove Sys V Init support from RPM distribution.#106

Remove Sys V Init support from RPM distribution.#106
JohanSaaw wants to merge 11 commits intoLMS-Community:public/9.2from
JohanSaaw:public/9.2

JohanSaaw commented Feb 24, 2026

Uh oh!

JohanSaaw commented Feb 24, 2026

Uh oh!

michaelherger left a comment

Uh oh!

michaelherger Feb 24, 2026

Uh oh!

JohanSaaw Feb 24, 2026

Uh oh!

mavit commented Feb 26, 2026

Uh oh!

mavit Feb 26, 2026

Uh oh!

JohanSaaw Feb 26, 2026

Uh oh!

mavit Feb 26, 2026

Uh oh!

mavit Feb 26, 2026

Uh oh!

JohanSaaw Feb 26, 2026

Uh oh!

mavit Feb 26, 2026

Uh oh!

JohanSaaw Feb 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		# send USR1 to lyriuonmusicserver PID to reset logging
		/bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 \|\| true

	/bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 \|\| true
	systemctl --kill-whom=main --signal=USR1 kill lyrionmusicserver.service

		/usr/bin/systemctl enable %{shortname}.service >/dev/null 2>&1 \|\| :
		/usr/bin/systemctl restart %{shortname}.service >/dev/null 2>&1 \|\| :

Conversation

JohanSaaw commented Feb 24, 2026

Uh oh!

JohanSaaw commented Feb 24, 2026

Uh oh!

michaelherger left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mavit commented Feb 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants