Systemd 254 released, deprecating sysvinit scripts

44 112 3 years ago

genmud• 3 years ago

Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.

rubiquity2• 3 years ago

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.

Bombinator• 3 years ago

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

washadjeffmad• 3 years ago

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.

mqus• 3 years ago

"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.

bravetraveler7• 3 years ago

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.

vkazanov2• 3 years ago

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.

haolez2• 3 years ago

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).

Karellen• 3 years ago

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.

throwawa14223• 3 years ago

Instead of complaining just drop anything that contains Systemd. I did and my frustration with IT related tasks has gone way down.

stingraycharles• 3 years ago

I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.

Aardwolf• 3 years ago

But how can I do that if I like Archlinux for the rest but everything around is based on Systemd, and most other distros also do that?

arjvik• 3 years ago

Try Artix Linux instead! It's essentially Arch, but with an alternative unit system.

op00to11• 3 years ago

Huh. Since learning more about systemd my frustration with IT related tasks has gone way down.

Unit files are far more functional for the same amount of effort as SysV scripts.

lloeki• 3 years ago

beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.

ticviking2• 3 years ago

Unit files seem like a good idea. Does systemd need to do everything it does in order to gain that benefit?

ticviking2• 3 years ago

I'm curious what alternative you make use of.

My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.

tekla2• 3 years ago

I've ported dozens of services many production critical over to SystemD over several companies. The only thing I've ever had issue with is systemd-timesyncd. Otherwise, its been rock solid. What the hell are you doing that gives you so much trouble with SystemD

bravetraveler7• 3 years ago

Ditto, much success with systemd here.

The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably.

If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability.

What was once tailored in scripts for each service/job/whatever is now provided by the system

It's about clearly laying out dependencies. Not a lot more.

The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced at work. It's common for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.

palebluedot• 3 years ago

I find systemd amazing, and worlds better than sysvinit. I'll be happy to never admin a sysvinit box again!

sophacles3• 3 years ago

I don't know how I feel about the implication that sysvinit ever did something that could be called "working".

bogwog• 3 years ago

What kind of frustrations has systemd caused you? I know there are a lot of very valid criticisms of it, but the only time I’ve experienced actual frustration is when I’m fighting with the timer syntax that I can never seem to memorize.

Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.

TacticalCoder3• 3 years ago

I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a systemd-less fork is to not forget that Linux still works fine without systemd.

Linux is not systemd.

I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux.

The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development.

But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't.

Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere.

Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional.

People should at least acknowledge there are reasons to be concerned about that.

And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.

stryan2• 3 years ago

Poettering didn't join Microsoft until 2022, systemd has been around since 2010.

kaba07• 3 years ago

What a shit take.. system boot is a complex problem requiring a monolith solution, otherwise you just building some Rube Goldberg machine. The same way the kernel is a fucking huge monolith.

Also, what would be the point with Poettering? What does he gain from being constantly criticized by lunatics? Like honestly, these takes are some jewish space laser level ones.

kaba07• 3 years ago

I would also have no IT related problems if my computer wouldn’t boot..

Arnavion• 3 years ago

Previous discussion: https://news.ycombinator.com/item?id=36513889

j16sdiz• 3 years ago

told you.

Just like pulsed, he won't stop until every existing, non-default config breaks. Just like pipewire, he will start a "better" alternative and restart the stuff breaking cycle

pantalaimon• 3 years ago

pipewire was not started by Lennart Poettering

pxc• 3 years ago

and also it really is better— and quite stable already!

stryan2• 3 years ago

systemd's been the default init for every major distro since 2015[0], and has existed as a project since roughly 2010. I think ten years of support for the predecessor is probably good enough. This is just a warning anyway.

Lennart also didn't start Pipewire (which as far as I know, has been happily accepted by almost everyone?) and while I was just as annoyed at PulseAudio breaking my sound setup back in 2008 I think these days it's a bit remiss to keep bringing that up as an argument. At least not without talking about how a lot of the issues with it was due to Pulse revealing bugs in the sound card drivers.

[0] Going by https://en.wikipedia.org/wiki/Systemd#Adoption and yes I'm only counting Arch,Debian,Ubuntu,Fedora,SUSE,and RHEL as the major distros. I could see an argument for Mint or Gentoo in there, but most of that table is honestly pretty useless (I still have my Knoppix floppies as coasters, but I really don't care about whether they've adopted systemd at this point)

EDIT: mild edit, sorry it was Wolvix I have as floppies. Knoppix was only on CDs and I'm not sure where mine went.

throw7• 3 years ago

Embrace, Extend, Extinguish.

mort962• 3 years ago

There was no embrace step; systemd served to replace sysvinit with a new way of doing things, supporting sysvinit scripts for backwards compatibility only.

There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd.

EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.

Brian_K_White2• 3 years ago

But it never actually did support sysv init scripts, because it fundamentally can't. All it has is ExecStart which is trivial garbage that does not replicate or emulate sysvinit functionality at all.

I had a tiny little simple 2k init script that managed lxc containers.

It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time

All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k.

Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself.

It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc.

The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor.

I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for.

In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs.

Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary.

The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say.

Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1?

I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid.

systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture.

And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.

op00to11• 3 years ago

This is a low effort post. Please don’t do that here. What about these words compelled you to post them? Tell us what’s in your brain!

photonbeam• 3 years ago

Is there a good systemd book to learn it all?

matthews22• 3 years ago

It has a very good manual. Lennart's blog also has a series named systemd for Administrators: https://0pointer.de/blog/projects/systemd-for-admins-1.html

op00to11• 3 years ago

I have answered all my systemd questions with the manual/manpage.

pkaye• 3 years ago

I haven't read this myself but you can download it for free.

https://opensource.com/downloads/pragmatic-guide-systemd-lin...

javajosh2• 3 years ago

Can we all just take a moment to laugh at the fact that all of this complexity is, roughly speaking, the evolution of AUTOEXEC.BAT?

(Pedants: I know AUTOEXEC.BAT not a direct ancestor of systemd, but it's a close cousin and serves the same purpose: run stuff when you boot.)

taf2• 3 years ago

I want my cake and it to boot fast too.

TacticalCoder3• 3 years ago

I saw that very often but I run a very lean Devuan (a Debian fork without systemd) and it boots ultra-fast too.

Machines and especially SSDs have gone a long way since ten years ago and people think Linux boots fast "thanks to systemd"... But I'd encourage these people to install Devuan just to give it a try. It may boot a tiny bit slower than Debian (for an identical system) but it's still very quick.

Put it in another way: the savings systemd did brought regarding booting times in 2015 aren't looking anywhere near as impressive today. I don't even know: on my 7700X I think from boot (since the moment I enter the disk decryption password) to (text mode) login prompt it take about a second under Debian (systemd)? Maybe it takes 1.5 seconds running Devuan (non-systemd)?

I mean: 20 seconds instead of 45 seconds may have seen like a bit saving in 2015 but 1 second vs 1.5 second, I don't give a rat's arse.

And people who really need super fast boot times in containers shall use Alpine without systemd anyway.

johnday• 3 years ago

That's not really fair. systemd does a lot more, and with good reason (among other reasons: there are many, many economies that can be made when "booting" and "managing" services happens in the same hat)

javajosh2• 3 years ago

That's not really fair

Uh, what? It's not fair to say that a vastly more complicated thing evolved from a simple thing? That's how it always happens - each step seems reasonable, and justified, but you look at what those countless rational decisions added up to, and bam. That's the complexity everyone says they hate. In technology, in government, in basically everything.

(Oddly, culture seems to be okay deprecating old bits of culture; the brain is inherently finite so we run in cycles and epicycles of cultural fashion that remains roughly at the same level of complexity.)

op00to11• 3 years ago

COMMAND.COM is a far more closer “relative” to SystemD than AUTOEXEC.BAT.

MikusR• 3 years ago

AUTOEXEC.BAT is same thing as a sysvinit script.

bravetraveler7• 3 years ago

Turns out launching something isn't enough, these days - interdependence, and all.

Took some decades to collectively get tired enough to decide on a language to declare it

cpach• 3 years ago

I think systemd is quite good.

For those who doesn’t like it: There are other service managers out there. IMHO the most sophisticated alternative is s6-rc.

It runs on both Linux and *BSD.

https://skarnet.org/software/s6-rc/

supriyo-biswas3• 3 years ago

I simply don't get the outrage/criticism against this part of systemd. Instead of having to play around with `start-stop-daemon` and whatnot, a simple service is just these days:

```

[Unit]

Description=my app

[Service]

Restart=on-failure

User=webservices

Group=webservices

ExecStart=/usr/local/bin/my-web-service

[Install]

WantedBy=multi-user.target

```

It couldn't really be any simpler.

There's also https://github.com/gdraheim/docker-systemctl-replacement# for anyone who needs a "lighter" alternative for tests in Docker.

tazjin• 3 years ago

Some people don't want simple and comprehensible. They want to run unnecessarily complex scripts in black terminals with green fonts. Let them be, somebody has to operate all the remaining PHP web pages out there.

supriyo-biswas3• 3 years ago

To be fair, after reading the thread about how people are voting with their feet about systemd-based distributions, I think there's a fair bit of trolling in this thread.

"Dropping systemd" would mean that they either use containers in an OS that most likely uses systemd itself, or they otherwise use some niche distribution (such as Antix, Devuan) that I've never heard of being used widely in a production context.

Other aspects of systemd might need getting some used to, but it's nothing that a reading of the Archlinux wiki didn't solve.

doctorpangloss2• 3 years ago

It couldn't really be any simpler.

It could. Ask ChatGPT4 for a bash script that writes the unit for you into the right place.

Colossal amounts of drudgery, all suddenly gone. The problem was never the opinions for how things were done, it was always the drudgery of reading documentation. Now, poof.

supriyo-biswas3• 3 years ago

If we're going to use the "just use GPT" response, you could ask ChatGPT for a systemd unit.

Also, this completely ignores the fact that GPT4 will often make up functions or make incorrect assumptions about how a language feature works (and I've seen it make several mistakes wrt shell quoting and the like), making it unusable for writing production code when you don't know the domain yourself. If you now have to debug the script, the use case of LLMs is gone.

bananapub5• 3 years ago

I really cannot believe how much worse HN comments have got over the past few years, from an already pretty annoying point.

just...wow.

ElectricalUnion2• 3 years ago

Ask ChatGPT4 for a bash script that writes the unit for you into the right place. Colossal amounts of drudgery, all suddenly gone.

Given that humans can't write reliable bash scripts that don't randomly delete things in your computer [1], why would you expect something generated by LLMs to not randomly delete things on your computer or worse?

If you have to inspect and debug whatever the AI generated, that is potentially a lot worse that just writing it yourself in the first place.

[1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

mort962• 3 years ago

I get the criticism which essentially boils down to, it's turning what used to be a "bazaar" into a "cathedral". Instead of the init system, udev, dbus, logging, networking, dhcp, run levels, cron, login system, etc. being separate systems bound together with duct tape, they're now one coherent system layer called systemd. I personally really like that, but I get why others wouldn't.

I don't get the outrage here about this decision though. If you were relying on systemd's sysvinit script support, you were already using systemd. And systemd .service files are strictly better than sysvinit scripts if you're already running systemd.

Pxtl• 3 years ago

To me that's the proper evolution. As knowledge of a problem matures, it makes sense to mash the best-practices together into a single monolith that's designed to work together with minimal bubble-gum. The Cambrian explosion of small tools makes sense early-on but the cognitive load of that approach is much higher, and some of us have crap to do.

voidr• 3 years ago

Most people complaining about systemd wouldn't even notice if their whole OS was just a single binary.

This attitude does not help the Linux stack, because the one thing software vendors do not have time for is to test against 10+ init systems[1].

I don't need both Wayland and X11, I just need one of these that is reliable.

I also don't need both Flatpak and Snap, I just need only one that does not have crippling bugs.

I also do not want to care about what version of glibc is on the target machine, I just want to compile a blob that anyone using any distro can run.

Choice is good, however not when it comes to the base system, the base system needs to be there and it needs to be reliable and people should build good stuff on top of that, init systems are not exciting things to build.

[1] https://wiki.gentoo.org/wiki/Comparison_of_init_systems

sharts• 3 years ago

I wish there was a command to just generate one of these files instead of always having to look it up, copy/paste, and then fill it all in.

It's the simple things that reduce friction that matter. Devs never understand this.

CogitoCogito• 3 years ago

General question: what do most people here dislike about systemd now? Binary logs? Logind? I mean this out of general curiosity. I’ve used systemd a fair amount and I don’t really fight it, but I’m not in love with it or anything.

TacticalCoder3• 3 years ago

what do most people here dislike about systemd now

Microsoft / Poettering controlling PID 1 development. As simple as that.

It could be better on technical merits (I'm 100% convinced systemd ain't the be-all end-all of init/services scripts / PID1 though), I still hate Poettering's attitude. And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.

bananapub5• 3 years ago

and that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.

er...what on earth are you talking about?

as far as I recall, people complained about Lennart because:

1. they didn't like his attitude (lol)

2. they didn't want "init" to do so much, which was mostly just people not bothering to actually look into systemd-the-binary vs systemd-the-project was

3. random specific technical complaints like journald not using plain text or unit files being ini files or whatever

edit: typo

it's the ultimate fuck you to people who believed in Linux since the beginning.

out of interest, when in the 90's do you feel this was?

does it only apply to people who used slackware 1.0? or just SLS users? or does one have to have received a tarball from Lars directly?

pengaru• 3 years ago

And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.

I'm sure Lennart was thinking about maximizing tribal offense while evaluating his stable employment options in the midst of RedHat's obvious decline.

The list of employers for a full-time upstream systemd maintainer at a competitive salary is rather short. And none of them are particularly attractive in terms of how dirty you'll feel having their logo on your paychecks.

ninjin• 3 years ago

I am not sure and I have used systemd through NixOS in particular for a good half a decade now. While I have not tried to fight it, it does come across as being somewhat opaque to me, but I can generally deal with it and have not gone out of my way to “read a book” on it. It did annoy the hell out of me about a month ago when I had this “conversation” with it:

    > sudo reboot
    [sudo] password for ninjin:
    Failed to reboot system via logind: Connection timed out
    > sudo halt
    Failed to set wall message, ignoring: Connection timed out
    Failed to reboot system via logind: Connection timed out

Never expected to be in a situation where I could not shut down a machine cleanly like that. But maybe I was missing something?

freedomben3• 3 years ago

Try `sudo systemctl reboot`. I've run into that issue in the past and somehow that worked.

On Fedora 37 `reboot` is `/usr/sbin/reboot` which is a symlink pointing to `/usr/bin/systemctl` so I don't know why it would matter, but I'll chalk it up to FM

traverseda• 3 years ago

OpenRC does most of the stuff that systemd does but better, and has existed for longer.

SystemD is architected in a way that makes significant security issues all but inevitable. There's just too much code running in PID 1 to be able to audit, too big of an attack surface.

Binary logs are frankly pretty annoying, but probably really helpful if you're in a large enterprise environment.

Locality of behavior is another annoyance, some services require a bunch of unit files to work well. One `.service`, another `.socket`, maybe a timer. There are also something like 6 different locations a unit file can live, depending on how it was installed, who owns it, etc. This is once again great for enterprise customers but means that if you want to find a unit file you can't just look in a directory, maybe a users home dir if it's a user service. You have to memorize or look up the systemd command that tells you where the unit files actually is. Same problem with unit file overrides. Overrides aren't just `myunit.service.override` or something next to your service, they live in their own folder and you need to use systemd commands to find/edit them.

Basically it discourages general unix knowledge in favor of memorizing a huge number of systemd specific commands, it does this by hiding files all over the place, using binary logs, and otherwise going out of their way to make themselves incompatible with unix-as-a-programming-environment.

They also make controversial decisions that you're probably shielded from by your distro, things like killing long-lived tmux sessions. Changing the behavior of your lid switch with no warning. They break a lot of stuff and when they do they're very unsympathetic about it. I recognize that they get a lot of hate, but when I look at issue trackers I often see people on the SystemD side being unprofessional first and escalating minor disagreements.

Can't launch systemd services in a chroot either, you need to be running systemd as pid 1 on your host system if you want to work with any kind of embedded linux that uses systemd.

nikau• 3 years ago

I don't mind it now, but in the earlier days it was pretty buggy.

Now I'm just at the "minor annoyance" stage as I don't do admin stuff much anymore, and I have to google stuff that used to be easy when I need to do something.

eg. in the past you could just type /etc/init.d/something <press tab> and it would show you services matching that prefix.

For logs, you could just go "cd /var/log && egrep blah *" to look for something.

Now of course I could write some wrapper functions for that using fzf or whatever to make life easy, but that's not always viable if you manage a fleet of hosts with restrictions where you don't have your custom bash profile and required utilities installed.

_jal2• 3 years ago

Personally I'm much more annoyed by taking control of how I partition my fucking drives.

Yes, I know why. IBMHat makes me like FreeBSD more with every power grab.

tjoff2• 3 years ago

How does it do that?

_jal2• 3 years ago

By making Linux less attractive to me.

jauntywundrkind• 3 years ago

It has great optional support for Discoverable Partitions, which has made writing custom kernel cmdline's optional. https://uapi-group.org/specifications/specs/discoverable_par...

Systems is also are deprecating non merged-/usr.

pwdisswordfishc• 3 years ago

What is it exactly that is being deprecated here? systemd-sysv-generator? If the unit generator interface is stable, what's to stop downstream distributions from keeping using it regardless?

op00to11• 3 years ago

I think it’s being able to have stuff in /etc/init.d that show up as services in SystemD.

bravetraveler7• 3 years ago

That's my read/thought too. The generator is lost, and distributions will probably be carrying an analogue forward -- for benefit of third party relics.

I don't believe it makes much more assumption than... $script {start,stop,restart} as the Exec lines in the unit

The hairy part is how package scriptlets and so on that assume SysV/want old utilities -- eg: chkconfig, service.

systemd captured these, and that may go away too

bananapub5• 3 years ago

discussions like this are good reminders of how low quality most HN threads are. a huge mass of random whinging about the people involved, non-technical whinging about imagined architecture decisions (like "systemd is a monolith") and then conspiracies about Microsoft like it's a slashdot thread in 1998.

notably missing:

- discussions about how fucking shit PID files and things like start-stop-daemon are or how annoying it was writing a sh script for every daemon, or how in sysvinit things can become un-shut-downable

- discussion about how making containerisation/chroot/resource limits trivial is good actually

- reflections on how hard making a reliable good init system is, cf upstart/launchd/whatever solaris had and how nice it is that someone actually did it for linux

etc etc

sophacles3• 3 years ago

Don't forget the single biggest problem of sysvinit:

Making services start in a deterministic order when the appropriate (and necessary) resources are actually available.

bananapub5• 3 years ago

dunno what you mean, my "start) sleep 15" works fine most of the time !

ElectricalUnion2• 3 years ago

I would add

- making handling of forking to the background and log rotation not a task of the program itself, instead of making every program (or worse, a bespoke wrapper shell script) do it.

Because such things are non-trivial and demand reasonably many man-hours of otherwise "trivial" projects.

Granted, you don't actually need systemd to do such things (for example, runit can do such things, and runit is available under busybox and therefore almost universal in most GNU/Linux distros), but I think it was systematic distro/systemd that enforced such new paradigm.

Systemd 254 released, deprecating sysvinit scripts

Related Stories