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