Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, Aug 07, 2023 at 16:44:43 +0200, Lennart Poettering wrote: >> 0. systemd implements SysV-compat disable knob, > > We do since about forever. Hmmm... I'm using systemd since v37 (reading all the release notes) and it's a bit of new to me... I've just run through some docs and can't find anything neither. It might be some documentation issue then. I hope you're not referring to -Dsysvinit-path -Dsysvrcnd-path? As I meant the runtime-knob. >> 1. distributions use SysV-disabled by default, allowing users to switch >>it on when needed, therefore it's impact is reduced, but notes >>taken, > > This is outside of our control. Did you gave us the tooling required for disabling this? The runtime-togglable one? You can't expect any user-oriented distro would disable this without an _easy_ way to reenable by user themself. >> 2. systemd enables some irritating behavior for SysV-enabled systems, >>like 30 second sleep with console beeping or rotating the screen >>upside down, > > We do log about this loudly, even with emojis since a while. > > I am pretty sure this should suffice. Do you expect users to read the logs? ;D Logs are passive, you need an _active_ distractor. > We didn't "just remove" it btw. We just announced that we'll remove it. Fully aware of it. And looking forward to it, as I expect more vendors to provide native units. I've written enough SysV-style inits in my life to really, really want them gone. Therefore I fully support your decision to finally disable the compat glue. The sooner, the better. I would have disabled them myself a long time ago, but I'm not aware of any switch (just masking the units or removing the files or generator). > It seems to me you are complaining that we are announcing the removal > ahead of time telling us to announce this ahead of time. Which doesn't I'm not complaining, just anticipating the shitstorm that's coming. And I'd like to be minimal, as this technically and objectively correct decision doesn't deserve the subjectively reasoned complains that will follow. Because I've read the announcement (not if that matters to me anyway, getting rid of SysV for years, I'd like my systems to ignore them entirely) and I know most users won't. Until the change is going to strike them in their faces. Just like the GNU/screen-killing on logout. This was the right thing to do, but some people are emotionally attached to their workflows: https://xkcd.com/1172/ > Consider this NEWS file entry your "stimulation" to transition the > holdouts. End-users with their 'curl http://example.net/ | bash -c' are out of scope of this and the distribution capabilities to inform them. All I'm saying is that you shouldn't disable it silently (release notes, logs - they ARE silent). No matter when it's going to happen, it should be end-user VISIBLE before that date and _some_ drop-in salvation should be available for them, buying some time for updating inits. Anyway, that's just my 2 cents hoping the road ahead to be less bumpy. -- Tomasz Pala
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mo, 07.08.23 16:24, Tomasz Pala (go...@polanet.pl) wrote: > > or to turn this around: this is only the way how people get off their > > asses and port the stuff over apparently. Nothing else worked for them. > > - nothing was truly done to make this happen. Well, what do you expect us to do? Patch cisco software ourselves? > Before removing the SysV-compat glue entirely, there should be > transition period. > > 0. systemd implements SysV-compat disable knob, We do since about forever. > 1. distributions use SysV-disabled by default, allowing users to switch >it on when needed, therefore it's impact is reduced, but notes >taken, This is outside of our control. > 2. systemd enables some irritating behavior for SysV-enabled systems, >like 30 second sleep with console beeping or rotating the screen >upside down, We do log about this loudly, even with emojis since a while. I am pretty sure this should suffice. > 3. systemd removes SysV-compat entirely. We aren't removing it yet. We are just telling people that we will. For those living under a rock. > The point is - people don't follow any NEWS, Warnings nor logs, and > then, after some update, they're in a revert-or-die situation. > > It's not their fault - no everyone is sysadm, people just want to use > some random packages provided by their vendors. > > Gradual transition needs to be stimulated, otherwise you end up with > some boycottsystemd rants. Just-remove approach is nice for programmers, > but contradicts the least-surprise principle without regular users being > warned in step-by-step escalation. We didn't "just remove" it btw. We just announced that we'll remove it. We are letting people know that this will go away. Distro maintainers are part of the intended audience of NEWS. They hopefully have noticed this now, and will forward the pressure on the holdouts. It seems to me you are complaining that we are announcing the removal ahead of time telling us to announce this ahead of time. Which doesn't make much sense to me. Consider this NEWS file entry your "stimulation" to transition the holdouts. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, Aug 07, 2023 at 15:22:38 +0200, Lennart Poettering wrote: > It's been 15 years. Stuff that has still not been ported over yet > should either be declared dead by now or finally be ported over. I > think this is generally in the interest of users. +1 BUT having said that: > or to turn this around: this is only the way how people get off their > asses and port the stuff over apparently. Nothing else worked for them. - nothing was truly done to make this happen. Before removing the SysV-compat glue entirely, there should be transition period. 0. systemd implements SysV-compat disable knob, 1. distributions use SysV-disabled by default, allowing users to switch it on when needed, therefore it's impact is reduced, but notes taken, 2. systemd enables some irritating behavior for SysV-enabled systems, like 30 second sleep with console beeping or rotating the screen upside down, 3. systemd removes SysV-compat entirely. The point is - people don't follow any NEWS, Warnings nor logs, and then, after some update, they're in a revert-or-die situation. It's not their fault - no everyone is sysadm, people just want to use some random packages provided by their vendors. Gradual transition needs to be stimulated, otherwise you end up with some boycottsystemd rants. Just-remove approach is nice for programmers, but contradicts the least-surprise principle without regular users being warned in step-by-step escalation. The distributions are important in that process, because each of them ruling their own defaults makes the process spread over time. The same reasoning should encourage them to cooperate in the process. After all, it's better to explain which knob to switch to restore SysV behaviour, than make it revert-or-nothing. I know that distros could simply create separate package for /lib/systemd/system-generators/systemd-sysv-generator but this won't be noticed unless this subpackage is NOT being pulled during upgrade, in which case users end up without the actual code required for SysV-reenable missing in their systems, i.e. much harder to recover than simple parameter change. Or - make all the sysv-generated units to ask for password before execution. No motivation means no progress. As a damage control - provide broken_sysv-compat@.service, being simple: ExecStart=/etc/init.d/%i start to be explicitly enabled as a last-resort solution. -- Tomasz Pala
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mo, 24.07.23 19:29, Jeremy Linton (jeremy.lin...@arm.com) wrote: > > Because I don't necessarily control what other people do. And there's > > still a very long tail of software out there that only ships a > > sysvinit script. There are still people upgrading from RHEL 5/6, SLE > > 11, or Ubuntu 14.04 too. The software they bring along that they can't > > change would still be using sysvinit scripts. > > A concrete example I ran into last week. The "Cisco Secure Client" which is > mandated in many places because it doesn't allow the user to disable the > "Cisco Secure Desktop trojan" like openconnect does. > > The latest (AFAIK) 5.x versions continue to drop a service into > /etc/rc.d/init.d/ciscod on generic linux platforms rather than providing a > systemd unit file. So you admit the current way to get them to provide proper unit files didn't work. Hence the next logic step for us: increase the pressure a bit now. We gave them enough time I think. > Maybe as a starting place throwing some loud errors in the > journal/console/etc might encourage people to clean this up. (forgive me if > its already doing that, I've not seen it). That has been in place for a while: https://github.com/systemd/systemd/blob/main/src/sysv-generator/sysv-generator.c#L767 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mo, 24.07.23 10:15, Neal Gompa (ngomp...@gmail.com) wrote: > On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot > wrote: > > > > * Support for System V service scripts is now deprecated and will be > > removed in a future release. Please make sure to update your > > software > > *now* to include a native systemd unit file instead of a legacy > > System V script to retain compatibility with future systemd > > releases. > > > > What's driving this change? Already distributions have to manage the > code that integrates the sysv init script support into systemd (such > as chkconfig(8) and debian's systemd-sysv-install for > update-rc.d(8)). It's been 15 years. Stuff that has still not been ported over yet should either be declared dead by now or finally be ported over. I think this is generally in the interest of users. We want to reduce the amount of legacy code we have to carry around and keep in mind. The init script mess is particularly nasty, since it's only half implemented, i.e. only if you invoke "systemctl enable" on the cmdline you'll get the sysv glue in place, if you do the same via dbus calls you don't. And we definitely don#t want the other half of the implementation, because it is terrible to fork such glue code off PID1. Besides for such services "systemctl edit", "systemctl set-property" and so on, are all broken and unavailable. That sucks. hence, this really should go, it's 2023. or to turn this around: this is only the way how people get off their asses and port the stuff over apparently. Nothing else worked for them. > Is this something that could be externalized into a separate project > and framework like systemd-initctl was? Perhaps it could even be a > pattern for others to implement translation for their own things to > systemd (e.g. runit, et al). Once the hooks from systemctl's client side are gone, they are gone. You can't really work around that. I am sorry, you want to convert runit service definitions to systemd? huh? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
Hi, On 7/24/23 11:57, Neal Gompa wrote: On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi wrote: On Mon, 24 Jul 2023 at 16:30, Neal Gompa wrote: On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot wrote: * Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software *now* to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases. What's driving this change? Already distributions have to manage the code that integrates the sysv init script support into systemd (such as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)). To the best of my knowledge, the sysv support code actually *in* systemd is mostly around the systemd-sysv-generator that creates transient units to express dependencies. There's also the small bits in systemctl(1) itself for triggering the generation of those units. Is this something that could be externalized into a separate project and framework like systemd-initctl was? Perhaps it could even be a pattern for others to implement translation for their own things to systemd (e.g. runit, et al). Why not just add a unit where it's missing? It's been a decade or so, most things should be in place now Because I don't necessarily control what other people do. And there's still a very long tail of software out there that only ships a sysvinit script. There are still people upgrading from RHEL 5/6, SLE 11, or Ubuntu 14.04 too. The software they bring along that they can't change would still be using sysvinit scripts. A concrete example I ran into last week. The "Cisco Secure Client" which is mandated in many places because it doesn't allow the user to disable the "Cisco Secure Desktop trojan" like openconnect does. The latest (AFAIK) 5.x versions continue to drop a service into /etc/rc.d/init.d/ciscod on generic linux platforms rather than providing a systemd unit file. Maybe as a starting place throwing some loud errors in the journal/console/etc might encourage people to clean this up. (forgive me if its already doing that, I've not seen it).
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, 24 Jul 2023 at 17:57, Neal Gompa wrote: > > On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi > wrote: > > > > On Mon, 24 Jul 2023 at 16:30, Neal Gompa wrote: > > > > > > On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot > > > wrote: > > > > > > > > * Support for System V service scripts is now deprecated and > > > > will be > > > > removed in a future release. Please make sure to update your > > > > software > > > > *now* to include a native systemd unit file instead of a > > > > legacy > > > > System V script to retain compatibility with future systemd > > > > releases. > > > > > > > > > > What's driving this change? Already distributions have to manage the > > > code that integrates the sysv init script support into systemd (such > > > as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)). > > > > > > To the best of my knowledge, the sysv support code actually *in* > > > systemd is mostly around the systemd-sysv-generator that creates > > > transient units to express dependencies. There's also the small bits > > > in systemctl(1) itself for triggering the generation of those units. > > > > > > Is this something that could be externalized into a separate project > > > and framework like systemd-initctl was? Perhaps it could even be a > > > pattern for others to implement translation for their own things to > > > systemd (e.g. runit, et al). > > > > Why not just add a unit where it's missing? It's been a decade or so, > > most things should be in place now > > Because I don't necessarily control what other people do. And there's > still a very long tail of software out there that only ships a > sysvinit script. There are still people upgrading from RHEL 5/6, SLE > 11, or Ubuntu 14.04 too. The software they bring along that they can't > change would still be using sysvinit scripts. This is not going to retroactively remove it though? So RHEL6 will still have it and so on. And when porting to different, more recent LTS distributions, there will be many other changes to do, adding a 3 lines unit file is likely going to be one of the easiest?
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi wrote: > > On Mon, 24 Jul 2023 at 16:30, Neal Gompa wrote: > > > > On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot > > wrote: > > > > > > * Support for System V service scripts is now deprecated and will > > > be > > > removed in a future release. Please make sure to update your > > > software > > > *now* to include a native systemd unit file instead of a legacy > > > System V script to retain compatibility with future systemd > > > releases. > > > > > > > What's driving this change? Already distributions have to manage the > > code that integrates the sysv init script support into systemd (such > > as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)). > > > > To the best of my knowledge, the sysv support code actually *in* > > systemd is mostly around the systemd-sysv-generator that creates > > transient units to express dependencies. There's also the small bits > > in systemctl(1) itself for triggering the generation of those units. > > > > Is this something that could be externalized into a separate project > > and framework like systemd-initctl was? Perhaps it could even be a > > pattern for others to implement translation for their own things to > > systemd (e.g. runit, et al). > > Why not just add a unit where it's missing? It's been a decade or so, > most things should be in place now Because I don't necessarily control what other people do. And there's still a very long tail of software out there that only ships a sysvinit script. There are still people upgrading from RHEL 5/6, SLE 11, or Ubuntu 14.04 too. The software they bring along that they can't change would still be using sysvinit scripts. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, 24 Jul 2023 at 16:30, Neal Gompa wrote: > > On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot > wrote: > > > > * Support for System V service scripts is now deprecated and will be > > removed in a future release. Please make sure to update your > > software > > *now* to include a native systemd unit file instead of a legacy > > System V script to retain compatibility with future systemd > > releases. > > > > What's driving this change? Already distributions have to manage the > code that integrates the sysv init script support into systemd (such > as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)). > > To the best of my knowledge, the sysv support code actually *in* > systemd is mostly around the systemd-sysv-generator that creates > transient units to express dependencies. There's also the small bits > in systemctl(1) itself for triggering the generation of those units. > > Is this something that could be externalized into a separate project > and framework like systemd-initctl was? Perhaps it could even be a > pattern for others to implement translation for their own things to > systemd (e.g. runit, et al). Why not just add a unit where it's missing? It's been a decade or so, most things should be in place now
