I did my regular Debian Unstable upgrade the other day, and this time I
noticed warnings about scripts in /etc/init.d lacking native systemd
service files.

Seems like the sysvinit compatibility that has been in systemd for so long
is on its way out ... I guess that means nobody cares about sysvinit any
more ...

On Thu, 24 Oct 2024 21:21:00 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> I did my regular Debian Unstable upgrade the other day, and this time
> I noticed warnings about scripts in /etc/init.d lacking native
> systemd service files.
>
> Seems like the sysvinit compatibility that has been in systemd for so
> long is on its way out ... I guess that means nobody cares about
> sysvinit any more ...

*sips coffee*

*runs Devuan*

On Thu, 24 Oct 2024 14:53:30 -0700, John Ames wrote:

> *runs Devuan*

How well is Devuan keeping up these days?

On Thu, 24 Oct 2024 23:19:44 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Thu, 24 Oct 2024 14:53:30 -0700, John Ames wrote:
>
>> *runs Devuan*
>
>How well is Devuan keeping up these days?

I've been using Devuan for years. You have a choice .. stable,
bit risky and bleeding edge. same as Debian. Without systemd, of
course.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012
Google Fuchsia - 2021

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> How well is Devuan keeping up these days?

Fine generally. I did just recently try to convert a free VPS on
Oracle Cloud over to it though and had to give up in the end. I
think the "cloud-init" system they use probably expects Systemd. It
might work better with their paid accounts where you can supply
your own OS image instead of my elaborate process converting Ubuntu
to Debian and then Debian to Devuan.

--
__ __
#_ < |\| |< _#

On Thu, 24 Oct 2024 23:19:44 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> How well is Devuan keeping up these days?

Just fine for my purposes...

On 24.10.2024 um 21:21 Uhr Lawrence D'Oliveiro wrote:

> Seems like the sysvinit compatibility that has been in systemd for so
> long is on its way out ... I guess that means nobody cares about
> sysvinit any more ...

This has been announced some time ago.

You can create a systemd unit to call your sysvinit script.

SysVinit is still being used on BSD and on Slackware Linux, so some
people still care about it, but not on systems with systemd.

--
kind regards
Marco

Send spam to 1729797660muell@cartoonies.org

Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>You can create a systemd unit to call your sysvinit script.

And use the Generator Template as, hm, yes, a template.

Debian's release goal for Trixie is that no init scripts are used on a
systemd system. We (Debian) are just behind Red Hat a little less than
a decade in this regard.

Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 25.10.2024 um 18:23 Uhr Marc Haber wrote:

> Debian's release goal for Trixie is that no init scripts are used on a
> systemd system. We (Debian) are just behind Red Hat a little less than
> a decade in this regard.

How will stuff be handled that involves more that just starting a
daemon, e.g. preparing certain stuff?
Should that all be packed in ExecStart=?

--
kind regards
Marco

Send spam to 1729873386muell@cartoonies.org

Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>On 25.10.2024 um 18:23 Uhr Marc Haber wrote:
>> Debian's release goal for Trixie is that no init scripts are used on a
>> systemd system. We (Debian) are just behind Red Hat a little less than
>> a decade in this regard.
>
>How will stuff be handled that involves more that just starting a
>daemon, e.g. preparing certain stuff?
>Should that all be packed in ExecStart=?

You can either ship a systemd unit that calls the init script or use
ExecStart and ExecStartPre et al. The holy war against scripts and
shells is one of the favorite beefs that I have with systemd. It's a
sound point from the security point of view, but it reduces the
usability and readability of Unit Files.

The exim4 packages are a case of this. The maintainer¹ has resorted to
(relevant parts only)
|Environment="EXIMSERVICE=-bdf -q30m" "UPEX4OPTS="
|EnvironmentFile=-/etc/default/exim4
|ExecStartPre=/usr/sbin/update-exim4.conf $UPEX4OPTS
|ExecStart=/usr/sbin/exim4 $EXIMSERVICE
|ExecReload=/usr/sbin/update-exim4.conf $UPEX4OPTS ; \
|kill -HUP $MAINPID

EnvironmentFile is something that the systemd people already wanted to
remove years ago (my opposition against this got me banned from
systemd-devel for some time), and I don't like the ExecReload part at
all. Sending a signal to the daemon and not waiting for confirmation
is explicitly not recommended in the systemd.service manual page, and
the fiddling with a MAINPID variable is something I don't like at all.
systemd can put all processes for a unit into its own cgroup and then
signal the cgroup, I would at least investigate this matter further.

Greetings
Marc

¹ I am still formally a member of this maintainer team but haven't
contributed in a decade.
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402