Le 26/06/2018 à 09:22, Jaromil a écrit :
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?
I think on the long term this horrible header of comments
describing the rc-scripts dependencies isn't sustainable. This has been
a temporary hack (~10 years ?) to provide a hierarchy among these
scripts. Better opt for startup systems which offer this functionality
natively and/or others which have a hardcoded sequence. I think there
are several out there - not counting the devil of course. In no way
would it discard sysv-init proper.
Didier
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
