[systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)

[Jeremy Linton]

Hi,

On 7/24/23 11:57, Neal Gompa wrote:
> On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi <luca.boccassi at gmail.com> wrote:
>>
>> On Mon, 24 Jul 2023 at 16:30, Neal Gompa <ngompa13 at gmail.com> wrote:
>>>
>>> On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot
>>> <donotreply-systemd-tag at refi64.com> 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).