Remove SysV init left overs/deprecate /sbin/service
Hi, We are now using systemd for a very long time, and there should be no reason anymore that anything depends on SysV init support. aaa_base still ships some of this leftovers: * /sbin/service * /usr/libexec/initscripts * /usr/libexec/initscripts/legacy-actions There is only one legacy package using /usr/libexec/initscripts, and this is "ntp". A SR to remove that is pending for over three weeks now. So since nothing is using that anymore, I would like to remove support for it from aaa_base. /sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service? /sbin/service is a complicated shell script, which tries to find out if a systemd service should be managed or a SysV init script. But we don't have SysV init scripts anymore and the remaining support will be removed upstream short or midterm. So most of the complex code can be safely removed. Remains the rc* symlinks. For what are they good? The only benefit is, that a user does not need to bother if this is a SysV init service or a systemd service. We don't have SysV init scripts anymore. So in the end it's always calling systemctl. Many systemd services don't have a rc* symlink, so people have to learn to use systemctl anyways. No other Linux distribution seems to have rc* symlinks, so they are not needed for compatibility. My proposal: * remove SysV init support from /sbin/service and add a deprecated notice * remove rc* symlinks * drop /sbin/service Regards, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Tue, Jun 18, 2024 at 9:55 AM Thorsten Kukuk via openSUSE Factory <factory@lists.opensuse.org> wrote:
Hi,
We are now using systemd for a very long time, and there should be no reason anymore that anything depends on SysV init support.
aaa_base still ships some of this leftovers: * /sbin/service * /usr/libexec/initscripts * /usr/libexec/initscripts/legacy-actions
There is only one legacy package using /usr/libexec/initscripts, and this is "ntp". A SR to remove that is pending for over three weeks now. So since nothing is using that anymore, I would like to remove support for it from aaa_base.
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/sbin/service is a complicated shell script, which tries to find out if a systemd service should be managed or a SysV init script. But we don't have SysV init scripts anymore and the remaining support will be removed upstream short or midterm. So most of the complex code can be safely removed.
Remains the rc* symlinks. For what are they good? The only benefit is, that a user does not need to bother if this is a SysV init service or a systemd service. We don't have SysV init scripts anymore. So in the end it's always calling systemctl. Many systemd services don't have a rc* symlink, so people have to learn to use systemctl anyways. No other Linux distribution seems to have rc* symlinks, so they are not needed for compatibility.
My proposal: * remove SysV init support from /sbin/service and add a deprecated notice * remove rc* symlinks * drop /sbin/service
I would prefer we drop all of it. I have already been removing them from my packages over time when I touch them. -- 真実はいつも一つ！/ Always, there's only one truth!
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
Hi,
We are now using systemd for a very long time, and there should be no reason anymore that anything depends on SysV init support.
aaa_base still ships some of this leftovers: * /sbin/service * /usr/libexec/initscripts * /usr/libexec/initscripts/legacy-actions
There is only one legacy package using /usr/libexec/initscripts, and this is "ntp". A SR to remove that is pending for over three weeks now. So since nothing is using that anymore, I would like to remove support for it from aaa_base.
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe. I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2. I also see /etc/init.d/jexec, but this one is a symlink dated 2015. "systemctl status vmware" works, but something creates the /etc/vmware scripts. "rcvmware status" also works. There are also after.local, boot.local, boot.localhw, which at some point were guaranteed to run for the foreseeable future ;-) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary... And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
I also see /etc/init.d/jexec, but this one is a symlink dated 2015.
Sounds like an update did go wrong and didn't remove that script.
"systemctl status vmware" works, but something creates the /etc/vmware scripts. "rcvmware status" also works.
The rc* symlinks in open-vm-tools need to be removed, too, see TODO list. I don't see a reason to postpone the project here.
There are also after.local, boot.local, boot.localhw, which at some point were guaranteed to run for the foreseeable future ;-)
I'm pretty sure that nobody ever made such a guarantee. For a simple reason: nobody has a crystal ball to see what will come in the future. Don't mix this up with "there are currently no plans to drop support for them". First, the support for these scripts is part of the deprecated systemd SysV Init support. So latest if this gets removed, you need to create your own systemd service for this. Second, and a much bigger reason to create your own systemd services: these scripts don't work in the same way with systemd as with SysV Init, because systemd cannot express the necessary dependencies as you would need for the same behavior. Thorsten
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary...
Oops. Typo. /etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package. ... Also, I still have: Telcontar:/etc/init.d # l -rw-r--r-- 1 root root 943 Jun 7 2013 .depend.boot -rw-r--r-- 1 root root 620 Jun 7 2013 .depend.halt -rw-r--r-- 1 root root 1771 Jun 7 2013 .depend.start -rw-r--r-- 1 root root 1116 Jun 7 2013 .depend.stop -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 6/18/24 05:33, Carlos E. R. wrote:
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary...
Oops. Typo.
/etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package.
...
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
On 2024-06-18 19:09, Shawn W Dunn wrote:
On 6/18/24 05:33, Carlos E. R. wrote:
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary...
Oops. Typo.
/etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package.
...
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
Leap is compatible with SLES. I do not consider dropping support for important proprietary packages a good business selling point. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Op dinsdag 18 juni 2024 19:23:47 CEST schreef Carlos E. R.:
On 2024-06-18 19:09, Shawn W Dunn wrote:
On 6/18/24 05:33, Carlos E. R. wrote:
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary...
Oops. Typo.
/etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package.
...
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
Leap is compatible with SLES. I do not consider dropping support for important proprietary packages a good business selling point.
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
Here's already one example of using VMware with systemd https://github.com/kriation/systemd-vmware -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
On 2024-06-18 19:29, Knurpht-openSUSE wrote:
Op dinsdag 18 juni 2024 19:23:47 CEST schreef Carlos E. R.:
On 2024-06-18 19:09, Shawn W Dunn wrote:
On 6/18/24 05:33, Carlos E. R. wrote:
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
...
/etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package.
...
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
Leap is compatible with SLES. I do not consider dropping support for important proprietary packages a good business selling point.
Here's already one example of using VMware with systemd https://github.com/kriation/systemd-vmware
Telcontar:~ # locate vmware.service Telcontar:~ # Telcontar:~ # systemctl cat vmware # /run/systemd/generator.late/vmware.service # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/vmware Description=LSB: This service starts and stops VMware services Before=multi-user.target Before=multi-user.target Before=graphical.target After=network-online.target Wants=network-online.target ... -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Remind me how dropping this in Tumbleweed affects Leap, in even one single way? You do understand that Leap is based on SLE, and as long as SLE supports SysVInit scripts, that's going to remain true for Leap. Just because a change gets made in Factory/Tumbleweed, that doesn't mean it automatically makes it into Leap. On June 18, 2024 12:23:47 PM CDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-06-18 19:09, Shawn W Dunn wrote:
On 6/18/24 05:33, Carlos E. R. wrote:
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary...
Oops. Typo.
/etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package.
...
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
Leap is compatible with SLES. I do not consider dropping support for important proprietary packages a good business selling point.
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
Am 18.06.24 um 20:32 schrieb Shawn Dunn:
Remind me how dropping this in Tumbleweed affects Leap, in even one single way? You do understand that Leap is based on SLE, and as long as SLE supports SysVInit scripts, that's going to remain true for Leap. Just because a change gets made in Factory/Tumbleweed, that doesn't mean it automatically makes it into Leap.
In practice it does. Most of the basically untested systemd-hardening stuff went also untested into SLES15 SPs where it caused problems. The "move config files from /etc/ to /usr/" stuff went into 15.6 where it causes data loss. Just two examples I experienced personally. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 2024-06-19 08:25, Stefan Seyfried via openSUSE Factory wrote:
Am 18.06.24 um 20:32 schrieb Shawn Dunn:
Remind me how dropping this in Tumbleweed affects Leap, in even one single way? You do understand that Leap is based on SLE, and as long as SLE supports SysVInit scripts, that's going to remain true for Leap. Just because a change gets made in Factory/Tumbleweed, that doesn't mean it automatically makes it into Leap.
In practice it does.
Most of the basically untested systemd-hardening stuff went also untested into SLES15 SPs where it caused problems. The "move config files from /etc/ to /usr/" stuff went into 15.6 where it causes data loss.
Just two examples I experienced personally.
Ow! Thanks for the telling! I thought the usr-etc change would not come till major version 16. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Wed, Jun 19, 2024 at 11:51 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
Ow! Thanks for the telling! I thought the usr-etc change would not come till major version 16.
Correct, usr-etc will not come for SLE15/Leap 15. There are more reasons for necessary configuration changes and cleanup, something which happens regularly with every Service Pack or new Leap version. So nothing new or unexpected. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Op woensdag 19 juni 2024 08:25:32 CEST schreef Stefan Seyfried via openSUSE Factory:
The "move config files from /etc/ to /usr/" stuff went into 15.6 where it causes data loss. Not yet, like Torsten says, did not happen. Here's the content of my 15.5 -> 15.6 upgraded VM to proove:
knurpht@localhost:~> ls -lah /usr/etc/ total 0 drwxr-xr-x 1 root root 6 Jun 19 13:48 . drwxr-xr-x 1 root root 124 Jun 10 20:15 .. drwxr-xr-x 1 root root 14 Jun 19 13:48 vpl knurpht@localhost:~> And yes, some initial step might have been made, but the /usr/etc move is definitely not there. -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
Am 19.06.24 um 14:15 schrieb Knurpht-openSUSE:
Op woensdag 19 juni 2024 08:25:32 CEST schreef Stefan Seyfried via openSUSE Factory:
The "move config files from /etc/ to /usr/" stuff went into 15.6 where it causes data loss. Not yet, like Torsten says, did not happen. Here's the content of my 15.5 -> 15.6 upgraded VM to proove:
knurpht@localhost:~> ls -lah /usr/etc/ total 0 drwxr-xr-x 1 root root 6 Jun 19 13:48 . drwxr-xr-x 1 root root 124 Jun 10 20:15 .. drwxr-xr-x 1 root root 14 Jun 19 13:48 vpl knurpht@localhost:~>
And yes, some initial step might have been made, but the /usr/etc move is definitely not there.
then why does systemd have this in %posttrans? (where it is too late and the data is already lost) posttrans scriptlet (using /bin/sh): if [ -e /etc/systemd/journald.conf.rpmsave ] && [ ! -e /etc/systemd/journald.conf ]; then echo >&2 "Restoring /etc/systemd/journald.conf. Please consider moving your customizations in a drop-in instead." echo >&2 "For more details, visit https://en.opensuse.org/Systemd#Configuration." mv -v /etc/systemd/journald.conf.rpmsave /etc/systemd/journald.conf || : fi -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Wed, Jun 19, 2024 at 5:03 PM Stefan Seyfried via openSUSE Factory <factory@lists.opensuse.org> wrote:
Am 19.06.24 um 14:15 schrieb Knurpht-openSUSE:
Op woensdag 19 juni 2024 08:25:32 CEST schreef Stefan Seyfried via openSUSE Factory:
The "move config files from /etc/ to /usr/" stuff went into 15.6 where it causes data loss. Not yet, like Torsten says, did not happen. Here's the content of my 15.5 -> 15.6 upgraded VM to proove:
knurpht@localhost:~> ls -lah /usr/etc/ total 0 drwxr-xr-x 1 root root 6 Jun 19 13:48 . drwxr-xr-x 1 root root 124 Jun 10 20:15 .. drwxr-xr-x 1 root root 14 Jun 19 13:48 vpl knurpht@localhost:~>
And yes, some initial step might have been made, but the /usr/etc move is definitely not there.
then why does systemd have this in %posttrans? (where it is too late and the data is already lost)
Where in this %posttrans is a move to /usr? A useless config template only creating update problems got removed. That's all. Thorsten
posttrans scriptlet (using /bin/sh):
if [ -e /etc/systemd/journald.conf.rpmsave ] && [ ! -e /etc/systemd/journald.conf ]; then echo >&2 "Restoring /etc/systemd/journald.conf. Please consider moving your customizations in a drop-in instead." echo >&2 "For more details, visit https://en.opensuse.org/Systemd#Configuration." mv -v /etc/systemd/journald.conf.rpmsave /etc/systemd/journald.conf || : fi -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Op woensdag 19 juni 2024 17:02:55 CEST schreef Stefan Seyfried via openSUSE Factory:
then why does systemd have this in %posttrans? (where it is too late and the data is already lost)
posttrans scriptlet (using /bin/sh):
if [ -e /etc/systemd/journald.conf.rpmsave ] && [ ! -e /etc/systemd/journald.conf ]; then echo >&2 "Restoring /etc/systemd/journald.conf. Please consider moving your customizations in a drop-in instead." echo >&2 "For more details, visit https://en.opensuse.org/Systemd#Configuration." mv -v /etc/systemd/journald.conf.rpmsave /etc/systemd/journald.conf || : fi Not related to the /usr move. It only mentions the usage of a drop-in snippet
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
Am 19.06.24 um 20:55 schrieb Knurpht-openSUSE:
Op woensdag 19 juni 2024 17:02:55 CEST schreef Stefan Seyfried via openSUSE Factory:
then why does systemd have this in %posttrans? (where it is too late and the data is already lost)
posttrans scriptlet (using /bin/sh):
if [ -e /etc/systemd/journald.conf.rpmsave ] && [ ! -e /etc/systemd/journald.conf ]; then echo >&2 "Restoring /etc/systemd/journald.conf. Please consider moving your customizations in a drop-in instead." echo >&2 "For more details, visit https://en.opensuse.org/Systemd#Configuration." mv -v /etc/systemd/journald.conf.rpmsave /etc/systemd/journald.conf || : fi Not related to the /usr move. It only mentions the usage of a drop-in snippet
The default config got moved to /usr when it was in /etc before. That move was executed poorly, to phrase it politely. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Op woensdag 19 juni 2024 22:05:48 CEST schreef Stefan Seyfried via openSUSE Factory:
The default config got moved to /usr when it was in /etc before. Not true, to put it mildly:
knurpht@localhost:/usr> ls -l total 0 drwxr-xr-x 1 root root 45578 Jun 19 13:52 bin drwxr-xr-x 1 root root 6 Jun 19 13:48 etc drwxr-xr-x 1 root root 44 Jun 10 23:20 include drwxr-xr-x 1 root root 4756 Jun 19 13:52 lib drwxr-xr-x 1 root root 117226 Jun 19 13:52 lib64 drwxr-xr-x 1 root root 10 May 19 01:39 libexec drwxr-xr-x 1 root root 66 Jun 10 20:13 local drwxr-xr-x 1 root root 12664 Jun 19 13:51 sbin drwxr-xr-x 1 root root 4674 Jun 19 13:50 share drwxr-xr-x 1 root root 16 Jun 10 20:13 src drwxr-xr-x 1 root root 26 Jun 10 20:13 x86_64-suse-linux knurpht@localhost:/usr> cd etc/ knurpht@localhost:/usr/etc> ls vpl knurpht@localhost:/usr/etc/vpl> ls vars.sh And that is all there is on the 15.5 -> 15.6 machine. So, no configs. -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
Am 19.06.24 um 22:15 schrieb Knurpht-openSUSE:
And that is all there is on the 15.5 -> 15.6 machine. So, no configs.
seife@server:~> l /usr/lib/systemd/logind.conf -rw-r--r-- 1 root root 1663 Mai 19 00:54 /usr/lib/systemd/logind.conf -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Wed, Jun 19, 2024 at 10:24 PM Stefan Seyfried via openSUSE Factory <factory@lists.opensuse.org> wrote:
Am 19.06.24 um 22:15 schrieb Knurpht-openSUSE:
And that is all there is on the 15.5 -> 15.6 machine. So, no configs.
seife@server:~> l /usr/lib/systemd/logind.conf -rw-r--r-- 1 root root 1663 Mai 19 00:54 /usr/lib/systemd/logind.conf
IIRC, that's from the systemd rebase, not from anything we did explicitly. -- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Jun 18, 2024 at 7:24 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 19:09, Shawn W Dunn wrote:
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
Leap is compatible with SLES. I do not consider dropping support for important proprietary packages a good business selling point.
Maintaining complex code for the next 20 years, which additionally prevents you from introducing or enabling new features, isn't a good business model, too. So the question is: is a proprietary VMWare package a better business selling point than all the other features, which we could enable or introduce? I strongly doubt it. Especially with the current plans of Broadcom with VMWare. If somebody needs VMWare, the answer is SLES15. It will exist until the end of 2037 or so. I'm pretty sure that there will be no VMWare anymore you can install on your machine at that point in time, if Broadcom continues with the current changes. If you don't need VMWare, but want all the nice new features, SLES16 is then the OS of your choice. There is absolutely no reason that a new SLES or Leap version needs to be able to support SysV init scripts, something we deprecated a decade ago, today. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 6/18/24 10:09, Shawn W Dunn wrote:
On 6/18/24 05:33, Carlos E. R. wrote:
On 2024-06-18 14:04, Thorsten Kukuk via openSUSE Factory wrote:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-06-18 09:54, Thorsten Kukuk via openSUSE Factory wrote:
/sbin/service is used by rc* symlinks by us. Is there anything else calling /sbin/service?
/etc/vmware, maybe.
A config file should not call a binary...
Oops. Typo.
/etc/init.d/vmware
And the vmware scripts in our open-vm-tools package will not use /sbin/service, as the network script they try to execute with it does not exist...
I see /etc/init.d/rc3.d/K50vmware and @K50vmware-USBArbitrator, @S50vmware and @S50vmware-USBArbitrator, and in level 5, 2.
Whatever that is, it doesn't seem to come from openSUSE.
No, they come from vmware player, a proprietary package.
...
I absolutely wouldn't advocate for holding up progress in openSUSE, due to the needs of some third party proprietary package. VMWare or not.
For what it's worth, the current Broadcom RAID controller management package drops a start/stop script called LsiSASH in /etc/init.d. It's a stand-alone script that's run manually if needed. I guess they drop it there because it's the logical place for it if they don't support anything else? Regards, Lew
On Tue, 18 Jun 2024 14:33:35 +0200, Carlos E. R. wrote:
No, they come from vmware player, a proprietary package.
vmware player is now deprecated, with VMware Workstation now being available for free for noncommercial use. But the point you make does stand for VMware Workstation as well. That said, it's pretty easy (and IIRC well-documented) how to switch that stuff over to use systemd (I've had my system set up to do that for some time now). -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 2024-06-18 19:34, Jim Henderson wrote:
On Tue, 18 Jun 2024 14:33:35 +0200, Carlos E. R. wrote:
No, they come from vmware player, a proprietary package.
vmware player is now deprecated, with VMware Workstation now being available for free for noncommercial use.
But the point you make does stand for VMware Workstation as well. That said, it's pretty easy (and IIRC well-documented) how to switch that stuff over to use systemd (I've had my system set up to do that for some time now).
I suspect that the installation script fails if /etc/init.d/ doesn't exist. I don't know, but I do not see a service file installed. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Tue, 18 Jun 2024 19:57:35 +0200, Carlos E. R. wrote:
I suspect that the installation script fails if /etc/init.d/ doesn't exist. I don't know, but I do not see a service file installed.
It doesn't. I've been running VMware Workstation on openSUSE distributions for years. And the service file is one that I pulled from a community resource years ago. The *removal* script is, to put it politely, a steaming heap of garbage (I have to manually remove the product every time I upgrade), but the installation works just fine. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On Tue, 18 Jun 2024 21:03:08 -0000 (UTC), Jim Henderson wrote:
On Tue, 18 Jun 2024 19:57:35 +0200, Carlos E. R. wrote:
I suspect that the installation script fails if /etc/init.d/ doesn't exist. I don't know, but I do not see a service file installed.
It doesn't. I've been running VMware Workstation on openSUSE distributions for years. And the service file is one that I pulled from a community resource years ago.
The *removal* script is, to put it politely, a steaming heap of garbage (I have to manually remove the product every time I upgrade), but the installation works just fine.
Oh, and if you want to run it on a TW kernel, you need to use a community- contributed git repo's code to get vmmon and vmnet to run. Getting it to run is non-trivial on TW (at least) without knowing more than enough to replace some sysvinit files with systemd service files. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
Am 18.06.24 um 14:04 schrieb Thorsten Kukuk via openSUSE Factory:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
There are also after.local, boot.local, boot.localhw, which at some point were guaranteed to run for the foreseeable future ;-)
I'm pretty sure that nobody ever made such a guarantee. For a simple reason: nobody has a crystal ball to see what will come in the future. Don't mix this up with "there are currently no plans to drop support for them".
First, the support for these scripts is part of the deprecated systemd SysV Init support. So latest if this gets removed, you need to create
I'm pretty sure we were sold systemd with the promise "your init scripts will continue to just work, just better" bach then. So it fits the picture of this project well that this compatibility is now going to be removed :-D Shows it's designed as a quality product ;-) (ahem, the only package which had catastrophic data loss during my 15.5-15.6 update was systemd-journald)
your own systemd service for this. Second, and a much bigger reason to create your own systemd services: these scripts don't work in the same way with systemd as with SysV Init, because systemd cannot express the necessary dependencies as you would need for the same behavior.
But they worked well enough still. "run pretty early during boot" (boot.local) and "run very late during boot" (after.local) without having to dig into all that stuff was a pretty useful feature for many. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
I'm pretty sure we were sold systemd with the promise "your init scripts will continue to just work, just better" bach then. So it fits the picture of this project well that this compatibility is now going to be removed 😀 And I'm pretty sure the of-course-not-forever-nuance was there. Which made me
Op dinsdag 18 juni 2024 15:14:20 CEST schreef Stefan Seyfried via openSUSE Factory: dive into systemd around 11.4(?) . And not regret it one single day. Yes I do have a history of writing initscripts, patching them over and over again due to f.e. new releases of the stuff the scripts were running. IMHO 12+ years after, it's good to clean that old stuff up. Having it means it has to be maintained too etc etc -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
On 2024-06-18 15:14, Stefan Seyfried via openSUSE Factory wrote:
Am 18.06.24 um 14:04 schrieb Thorsten Kukuk via openSUSE Factory:
On Tue, Jun 18, 2024 at 12:55 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
There are also after.local, boot.local, boot.localhw, which at some point were guaranteed to run for the foreseeable future ;-)
I'm pretty sure that nobody ever made such a guarantee. For a simple reason: nobody has a crystal ball to see what will come in the future. Don't mix this up with "there are currently no plans to drop support for them".
First, the support for these scripts is part of the deprecated systemd SysV Init support. So latest if this gets removed, you need to create
I'm pretty sure we were sold systemd with the promise "your init scripts will continue to just work, just better" bach then.
True.
So it fits the picture of this project well that this compatibility is now going to be removed :-D Shows it's designed as a quality product ;-) (ahem, the only package which had catastrophic data loss during my 15.5-15.6 update was systemd-journald)
your own systemd service for this. Second, and a much bigger reason to create your own systemd services: these scripts don't work in the same way with systemd as with SysV Init, because systemd cannot express the necessary dependencies as you would need for the same behavior.
But they worked well enough still. "run pretty early during boot" (boot.local) and "run very late during boot" (after.local) without having to dig into all that stuff was a pretty useful feature for many.
Indeed it is. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
But they worked well enough still. "run pretty early during boot" (boot.local) and "run very late during boot" (after.local) without having to dig into all that stuff was a pretty useful feature for many.
Indeed it is. Instead of moaning that it goes away, you could as well have expressed your appreciation for the devs and packagers that they kept it up this long. Don't
Op dinsdag 18 juni 2024 19:26:56 CEST schreef Carlos E. R.: play the victim-of-more-bad-decisions-card please. -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team
Moin, On Tue, 18 Jun 2024, 19:34:08 +0200, Knurpht-openSUSE wrote:
But they worked well enough still. "run pretty early during boot" (boot.local) and "run very late during boot" (after.local) without having to dig into all that stuff was a pretty useful feature for many.
Indeed it is. Instead of moaning that it goes away, you could as well have expressed your appreciation for the devs and packagers that they kept it up this long. Don't
Op dinsdag 18 juni 2024 19:26:56 CEST schreef Carlos E. R.: play the victim-of-more-bad-decisions-card please.
Come on, the deprecation has just been mentioned, not even been announced, by Thorsten, why do you blame people bringing up their comments this hard? I completely agree that most stuff should have been ported to use systemd units these days, but boot.local and after.local really are (have been) such an incredibly easy way to run arbitrary commands at a specific point when booting. This *is* something that the devs and packagers (I'm one of them fwiw) should appreciate as information what they might consider in maintaining... Cheers. l8er manfred
On 2024-06-18 19:42, Manfred Hollstein wrote:
Moin,
On Tue, 18 Jun 2024, 19:34:08 +0200, Knurpht-openSUSE wrote:
But they worked well enough still. "run pretty early during boot" (boot.local) and "run very late during boot" (after.local) without having to dig into all that stuff was a pretty useful feature for many.
Indeed it is. Instead of moaning that it goes away, you could as well have expressed your appreciation for the devs and packagers that they kept it up this long. Don't
Op dinsdag 18 juni 2024 19:26:56 CEST schreef Carlos E. R.: play the victim-of-more-bad-decisions-card please.
Come on, the deprecation has just been mentioned, not even been announced, by Thorsten, why do you blame people bringing up their comments this hard?
I completely agree that most stuff should have been ported to use systemd units these days, but boot.local and after.local really are (have been) such an incredibly easy way to run arbitrary commands at a specific point when booting. This *is* something that the devs and packagers (I'm one of them fwiw) should appreciate as information what they might consider in maintaining...
Surely it is not my personal fault if proprietary packages have not done the effort to migrate to systemd in these many years. I'm simply mentioning that one proprietary package that I happen to use has not migrated. Probably there are more. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Am 18.06.24 um 19:42 schrieb Manfred Hollstein:
I completely agree that most stuff should have been ported to use systemd units these days, but boot.local and after.local really are (have been) such an incredibly easy way to run arbitrary commands at a specific point when booting. This *is* something that the devs and packagers (I'm one of them fwiw) should appreciate as information what they might consider in maintaining...
+1 Maybe a "boot-early.service" and "boot-late.service" could be provided which just check for a directory "boot-{early,late}.d" and start all executables in there. I'll probably just whip up a pacakge that does that for me privately. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hi Seife, On 19.06.24 08:33 Stefan Seyfried via openSUSE Factory wrote:
Maybe a "boot-early.service" and "boot-late.service" could be provided which just check for a directory "boot-{early,late}.d" and start all executables in there.
I'll probably just whip up a pacakge that does that for me privately.
Why not whip this up and maintain it for other users, that might also find that useful? That would really help the people that like this behaviour. Kind Regards, Johannes (who has not used init scripts in a long time other than on openWRT and is really happy about that fact and the existence of systemd...)
Hi Thorsten, Am Di., 18. Juni 2024 um 09:55 Uhr schrieb Thorsten Kukuk via openSUSE Factory <factory@lists.opensuse.org>:
/sbin/service is a complicated shell script, which tries to find out if a systemd service should be managed or a SysV init script. But we don't have SysV init scripts anymore and the remaining support will be removed upstream short or midterm. So most of the complex code can be safely removed.
The main remaining purpose of that is to forward the call to systemctl.
Remains the rc* symlinks. For what are they good? The only benefit is, that a user does not need to bother if this is a SysV init service or a systemd service. We don't have SysV init scripts anymore. So in the end it's always calling systemctl. Many systemd services don't have a rc* symlink, so people have to learn to use systemctl anyways. No other Linux distribution seems to have rc* symlinks, so they are not needed for compatibility.
I'm outing myself as an oldschool person here. I love the rcXXX links, and this might be useful for SLE15/Leap 15 users to transition to SLES16/Leap16? We still have a lot of documentation out there that references it. being compatible with a non-SUSE is one thing, breaking compatibility with our own distribution documentation should be done with caution imho. what do you like more, a "command not found" or a "hey, going forward please call systemctl foo instead"?
* remove SysV init support from /sbin/service and add a deprecated notice * remove rc* symlinks
after sles16 branching, please. Greetings, Dirk
On Wed, Jun 19, 2024 at 9:19 PM Dirk Müller <dmueller@suse.com> wrote:
Hi Thorsten,
Am Di., 18. Juni 2024 um 09:55 Uhr schrieb Thorsten Kukuk via openSUSE Factory <factory@lists.opensuse.org>:
/sbin/service is a complicated shell script, which tries to find out if a systemd service should be managed or a SysV init script. But we don't have SysV init scripts anymore and the remaining support will be removed upstream short or midterm. So most of the complex code can be safely removed.
The main remaining purpose of that is to forward the call to systemctl.
That's what I wrote and why the SysV Init code can be removed?
Remains the rc* symlinks. For what are they good? The only benefit is, that a user does not need to bother if this is a SysV init service or a systemd service. We don't have SysV init scripts anymore. So in the end it's always calling systemctl. Many systemd services don't have a rc* symlink, so people have to learn to use systemctl anyways. No other Linux distribution seems to have rc* symlinks, so they are not needed for compatibility.
I'm outing myself as an oldschool person here. I love the rcXXX links, and this might be useful for SLE15/Leap 15 users to transition to SLES16/Leap16?
We said the same already from SLE12 to SLE15, and if we don't do it now, we will say the same from SLE16 to SLE17. As I wrote: most services have no rc* symlink, so you have to learn the use of systemctl anyways. So why think about every time again, if you can use a rc* symlink or if you need to use systemctl, why not using systemctl always?
We still have a lot of documentation out there that references it. being compatible with a non-SUSE is one thing, breaking compatibility with our own distribution documentation should be done with caution imho.
As written: most service files have no rc* symlink, so we cannot speak about a distribution specific standard here. And the documentation needs to be reworked anyways.
what do you like more, a "command not found" or a "hey, going forward please call systemctl foo instead"?
That's what I suggested to do?
* remove SysV init support from /sbin/service and add a deprecated notice * remove rc* symlinks
after sles16 branching, please.
There are several SLES16 feature requests to do it before SLES16, either requesting it direct or implicit. No, they are not from me. And if we don't do it now, we will not do it for SLES17 for the same reasons, too. Thorsten
Greetings, Dirk
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Hi Thorsten, Am Do., 20. Juni 2024 um 08:44 Uhr schrieb Thorsten Kukuk <kukuk@suse.com>:
The main remaining purpose of that is to forward the call to systemctl. That's what I wrote and why the SysV Init code can be removed?
of course. but you were saying "/sbin/service is a complicated shell script". I checked, the "forward call to systemctl" part is about 35 lines of shell. I think we can maintain that. Even for 20 years. no other dependencies other than shell, so it's not bloating the system.
I'm outing myself as an oldschool person here. I love the rcXXX links, and this might be useful for SLE15/Leap 15 users to transition to SLES16/Leap16? We said the same already from SLE12 to SLE15, and if we don't do it now, we will say the same from SLE16 to SLE17.
Well, we haven't committed a "warning, this will go away, use systemctl xxx instead" message. That's what I'd be looking for. You can even do exit 2 if $OPENQA_BE_PEDANTIC is set and we find internal uses of it.
As I wrote: most services have no rc* symlink, so you have to learn the use of systemctl anyways.
On my system about 50% have rc symlinks. but this is not a quantitative experience at all. The ones that I manually restart have rc links. I don't restart the others. rc<tab> gets me 90%+ there of what I want to do every day.
So why think about it every time again, if you can use a rc* symlink or if you need to use systemctl, why not using systemctl always?
It's a lot more typing, old habits die, and it's not about me. I can change. It's about everyone else.
As written: most service files have no rc* symlink, so we cannot speak about a distribution specific standard here.
It is a deprecated standard. I'm not arguing for continuing keeping it around or enforcing it. rpmlint has dropped the warnings that it used to have on this some time ago. I've seen people type rc<tab> and love it. It's a symlink, it costs no maintenance effort, it is not large in size (unlike other stuff that we carry around for compatibility) and we haven't properly informed the users about its removal. no deprecation warning message in sle12 or sle15.
And the documentation needs to be reworked anyways.
I think that'd be a great idea.
what do you like more, a "command not found" or a "hey, going forward please call systemctl foo instead"? That's what I suggested to do?
yeah, remove the sysv code. keep the systemctl forwarding with a "look you're a die hard like dirk is but going forward only systemctl xxx yyy will work" message and I'd be happy about it (add my patreon for donating me a coffee if you find the message useful). I can then tell you how much coffee I've received from our users.
There are several SLES16 feature requests to do it before SLES16, either requesting it direct or implicit. No, they are not from me. And if we don't do it now, we will not do it for SLES17 for the same reasons, too.
I'm all for removing sysv compat. Greetings, Dirk
participants (12)
-
Carlos E. R. -
Dirk Müller -
Jim Henderson -
Johannes Kastl -
Knurpht-openSUSE -
Lew Wolfgang -
Manfred Hollstein -
Neal Gompa -
Shawn Dunn -
Shawn W Dunn
-
Stefan Seyfried -
Thorsten Kukuk