Good riddance! Sysvinit shell scripts are a pain to read and maintain. Developers that perpetuate systemd flamewars have gone from mildly entertaining memes to being a serious red flag and not anyone I’d ever want to work with. systemd and its ecosystem is proven and always getting better.

Certainly! It can also be difficult to distinguish between being genuinely liked and politely tolerated because of being "good to have around".

I mean init systems, of course.

Don't you think it does a bit too much as an init system?

It’s not just an init system and you can opt into resolved, networkd, etc. but you knew that already!

No, it does what I want well. It never surprised me.

No. It’s great, replacing and unifying a whole collection of random tooling you otherwise had to cobble together yourself.

What does it do as an init system that is too much?

Not really, no. Systemd-init seems fairly focused. systemd the project also makes other stuff, which all neatly fits together.

Just being able to treat period tasks the same as I treat long-lived services, and never having to think about crontab vs cron.d vs cron.hourly vs /etc/crontab, has improved my quality of life dramatically.

I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).

I guess I didn’t get the hint that UNIX is not for me over two decades ago! Do you also dislike launchd and generally being productive?

I have no idea what launchd is.

Which is fair, since Linux Is Not UniX.

You do realise that sysvinit scripts are much, much, much more fragile?

Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.

The bag of spaghetti in systemd's case is not visible to you, but it's there in thousands and thousands of C code (and I use systemd).

Yes, systemd is far from trivial. The model of its operation is rather convoluted.

But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc.

There some questions around binary logs, yes, but nothing truly unbearable.

Can you define spaghetti in this context, and point to examples in the code?

My point is that the complexity is still there, but hidden.

There is good and bad code in systemd as there is good and bad sysv init scripts.

Which is the proper place for complexity to live in and get properly tested by millions of boots each minute. Remember, essential complexity of a task can never be reduced.

As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.

As someone else has pointed out, this is only a deprecation at this point.

For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal.

Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021.

Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.

"will be removed in a future release"

So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.

Yea, woe is me - having to be aware of an init system. If you want users, you'll cater to them. Distribution maintainers do.

Here's the Unit, what this provides:

    [Unit]
    Description=Whatever
    After=network.target network-online.target
    [Service]
    Type=forking
    ExecStart=/etc/init.d/your_awesome_initscript start
    ExecStop=/etc/init.d/your_awesome_initscript stop
    ExecReload=/etc/init.d/your_awesome_initscript restart
    [Install]
    WantedBy=some.target

For bonus points - and smaller repositories and more reliability...

... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd.

It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables.

Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement?

It's not removed yet, there's time.