On Tue, 26 Jun 2018 09:22:26 +0200 Jaromil <[email protected]> wrote: > 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,
Class act, that Debian project. > 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. Good luck with that. Sysvinit and OpenRC both have these 200 line init scripts: 200 lines not counting all the function definitions imported. And you just have to love the way each script must have five different scripts within it: Start, Stop, Restart, and two others I long ago forgot. Sysvinit and OpenRC were doable as long as somebody provided the init script, but creating these things could be a nightmare, and I doubt that anything less than state of the art AI could convert a simple and to the point systemd unit file to a wild and crazy sysvinit/openrc init file. I'll make a suggestion later in this post... > > 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. I understood that eventually Devuan will stand on its own, maintaining all its own packages. But until that day I agree with you, you can't fork everything not having a sysvinit/openrc init script, because then Debian would rush to drown Devuan in a deluge of such scriptless packages. > > 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? Well, not in an automated way, but I have a pretty good idea. Systemd, runit and s6 all share very simple and obvious daemon configs. I'm betting a knowledgeable person could read a systemd unit file and create either a runit run script or an s6 run script within 10 to 20 minutes. Then it can be run from runit or s6. I'm not saying abandon sysvinit and OpenRC. I'm saying run runit or s6 on top of them, and rely on runit or s6 to supervise software for which Debian declined to provide a sysvinit init script. Typical run scripts are less than 10 lines. Start, stop and restart are done by the supervisor, not by a case statement sub-part of a shellscript. And I predict, once run scripts are written, they'll need little or no change, regardless of what halloween code the Debian packagers throw in it. I think s6 might be the better choice, because it's more actively under development, and its feature set maps better to the (useful) features of systemd. https://skarnet.org/software/s6/ HTH, SteveT Steve Litt June 2018 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
