:: [DNG] strategy for missing sysvinit…
Top Page
Delete this message
Reply to this message
Author: Jaromil
Date:  
To: dng
Subject: [DNG] strategy for missing sysvinit scripts - the tuned case

dear dng'ers

today I gave a spin to 'tuned' prompted by this article
https://www.tecmint.com/tuned-automatic-performance-tuning-of-centos-rhel-servers/
and I quickly realised our package (from Debian) doesn't have any
sysvinit script, but only a systemd unit in
/lib/systemd/system/tuned.service containing:

[Unit]
Description=Dynamic System Tuning Daemon
After=systemd-sysctl.service network.target dbus.service
Requires=dbus.service polkit.service
Conflicts=cpupower.service
Documentation=man:tuned(8) man:tuned.conf(5) man:tuned-adm(8)

[Service]
Type=dbus
PIDFile=/run/tuned/tuned.pid
BusName=com.redhat.tuned
ExecStart=/usr/sbin/tuned -l -P

[Install]
WantedBy=multi-user.target

So I start thinking of what strategy we can adopt in order to overcome
this limitation.

Being a relatively simple CRUD / declarative configuration it may be
easy to generate scripts from the information contained in systemd
service configurations, or even wrap them runtime with a smaller
program executing their commands and called by sysvinit/openrc.

Another strategy which IMHO may not be sustainable on the long term is
to fork all packages to have such a sysvinit service script in them.
I tend to disagree with this approach.

After so many years, what are your opinions?

Is there a viable and smart way to work around this situation, just
like we did with amprolla thanks to Nextime's brilliant intuition?

ciao