Re: [DNG] strategy for missing sysvinit scripts - the tuned case
On Tue, 26 Jun 2018 09:22:26 +0200 Jaromil 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 Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] strategy for missing sysvinit scripts - the tuned case
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 Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] strategy for missing sysvinit scripts - the tuned case
...on Tue, Jun 26, 2018 at 09:22:26AM +0200, Jaromil wrote: > 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. Maybe create an additional companion package that just contains the sysvinit/openrc script? Though I have no idea how to declare the dependency without changing the original package. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] strategy for missing sysvinit scripts - the tuned case
On Tue, Jun 26, 2018 at 09:22:26AM +0200, Jaromil wrote: > > 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. Debian tried it during GSoC couple years ago: https://github.com/akhilvij/systemd-to-sysvinit-converter Maybe this could be revived and extended. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
