Re: Dropping SysV init script support? (was: systemd prerelease 254-rc3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 7/24/23 11:57, Neal Gompa wrote:
On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote:

On Mon, 24 Jul 2023 at 16:30, Neal Gompa <ngompa13@xxxxxxxxx> wrote:

On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot
<donotreply-systemd-tag@xxxxxxxxxx> 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).






[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux