We detached this subthread from https://news.ycombinator.com/item?id=18322395 and marked it off-topic.
2. (Close to 100% of) packagers and maintainers of system services
3. System administrators using distros from #1 (which is, again, practically everyone)
Similarly, having something worth switching to also depends on labor to develop such an alternative. Upstart is no longer funded, and was the closest (including in terms of mindshare that caused people to spend labor developing integration between their software and the init system).
The same should happen with the init system. Of course, it's different when the software pretends not just to be an init system but also a replacement for tons of other daemons like cron, inetd, networking, etc, making it a huge piece of software. But maybe that's the problem in the first place.
(And in this context it is probably useful to realize that on the kernel side of things the amount of funding from Red Hat and IBM is comparable)
I also don't think avoiding using systemd solves the problem. My preferred alternative to an abandoned systemd is a well-developed systemd, not sysvinit.
Having looked at the code. Calling it good software is a dubious proposition at best.
As mentioned in another comment. There are other init replacements that are seeking to solve the same issues as systemd. I bet you can’t name them though since they were never properly evaluated.
Not as cut and dry as you make it seem.
Debian uses ranked preference voting. Of the nine committee members, only one ranked sysvinit above either systemd or upstart. The rest were split about which of the two, with systemd winning the tie-break vote, but both were acceptable choices to all eight. There was no tie about whether systemd would have been an acceptable choice; both systemd and upstart were accepted 8-to-1.
The one member who voted in favor of sysvinit resigned after trying to start a general resolution (a vote of the entire project) to overrule the committee, and being told by basically everyone that this was inappropriate. He did not resign over systemd; he resigned, at best, over the process, and really I'd say he resigned because the project had lost confidence in him as someone able to act reasonably in contentious technical situations, which is basically the job of a technical committee member.
Nobody on the technical committee had refused to implement systemd support. The technical committee is not an implementation body anyway, but none of the members have refused to, say, implement systemd support in their packages, and they all remain members of the project.
All of this is public record, e.g.: https://lwn.net/Articles/585504/
(Also, none of what you said is a counterargument to the post you replied to.)
But you are mistaken if you think systemd is about init, it has gobbled so much stuff that this thing is a monstrous kitchen sink on its way to engulfing the whole bathroom.
then again maybe there are other init systems options than those two, devuan which arose from keeping systemd out of debian offert no less than 6 alternatives that address SysV flaws: openrc, sinit, runit, s6 and shepherd.
B: So you want to drive a horse-and-buggy then?
That is to say, there are quite a number of modern inits that are not systemd. It's such a straw-man argument to bring up sysv init every time someone says something critical of systemd.
A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems.
I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't.
I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago.
System components need to be well scoped and replaceable. There's a major design problem brewing in this area.
Is it possible to use one without the other?
/sbin/init is pid=1, the single process that the kernel starts when a system boots. It typically runs a command to kick off bringing up userland to the correct runlevel, maybe something like "/etc/rc.d/rc 3". It doesn't do anything more than just execute this command.
The command is part of the RC system. Typically written in shell, it handles walking /etc/rc.*/ and running the scripts contained therein to configure and invoke the various services for a particular runlevel.
You can boot linux using your own init and skip the rc system. From grub, add "init=/bin/sh" to your kernel parameters and you will get a shell as pid=1 and no other processes -- from there you can run commands as you wish to bring your system the rest of the way up. If you were to run "/etc/rc.d/rc 3" by hand you would invoke the same scripts that normally run on bootup to runlevel 3.
You could also delete all these shell scripts and replace them with your own code for configuring the system.
You have erroneously conflated rc and init, as others have pointed out.
I don't want to hold onto everything about SysV style systems - I love SMF in Solaris! - but I'd definitely prefer a leaner and more focused approach to development than we see with systemd.
You and I have very different definitions of modern, I suppose.
From a distance it looks like politics and influence pushed for adoption of systemd, motivation behind this uncanny move and spread has been questioned making some wonder if this could be intended with a nefarious purpose in mind.
Huh? I'm not sure what you think the role of Debian's TC is, you seem to be quite confused about it. Also, both TC members who preferred systemd over upstart and members who preferred upstart over systemd resigned.
The general volatility of systemd introduces so many unstable elements in your system, that it really makes you think if the added risk it is really worth the value it offers (even though I'm still not quiet sure what the value of systemd actually is).
- Services can depend on mounts, sockets, paths, or other servives. Don't start the NFS server until your backend storage is online and mounted and stop it if it goes offline.
- Are you annoyed when Symantec is chewing through your CPU? Use systemctl --edit and cap it at 20% with one CPUQuota option.
- Have a NodeJS service you want to bind to port 80 but not run as root? AmbientCapabilities=CAP_NET_BIND_SERVICE and you're done.
- Want to automount a directory? Drop in an .automount file or add an option to fstab and you're done.
- Replace GRUB with systemd-boot and enjoy configuring boot options with simple INI files.
- Want to do offline updates? Have any service you want be part of system-update.target, touch /system-update and reboot.
- Annoyed that you can't have more than 3 dns servers or can't run DNSoTLS or DNSoHTTPS? systemd-resolved has your back.
- Forget about ntpd or chrony and use systemd-timesyncd is a lightweight standards complaint ntp client.
- Run all your userspace daemons like offlineimap, tmux, emacs, your dev server, etc. as systemd user services.
- Manage the permissions, resource usage, and monitor long running jobs with systemd-run.
- Replace cron with systemd timers that not only have more powerful timespecs, are hooked into the dependency solver, and can be monitored like any other service.
- Isolate troublesome 3rd party applications with systemd-portable which are a bit like privileged containers but easier to use.
- Run apps as unprivileged users without having to fill passwd with users and groups just for services with dynamic users.
These are just the ones off the top of my head. It boggles my mind how people say that systemd doesn't provide value.
You’re arguing the same tired points against sysvinit except also attributing valour to systemd where it doesn’t belong.
- Services can depend on mounts, sockets, paths, or other servives. Don't start the NFS server until your backend storage is online and mounted and stop it if it goes offline.
This is what the next generation of init systems brought. Not just systemd, but runit and others. Nobody was fighting for sysvinit, which is what people seem to argue.
- Are you annoyed when Symantec is chewing through your CPU? Use systemctl --edit and cap it at 20% with one CPUQuota option.
This is just cgroups, a function of the kernel, not systemd
- Have a NodeJS service you want to bind to port 80 but not run as root? AmbientCapabilities=CAP_NET_BIND_SERVICE and you're done.
Polkit
- Want to automount a directory? Drop in an .automount file or add an option to fstab and you're done.
Automount, existed for 15 years at this point.
- Replace GRUB with systemd-boot and enjoy configuring boot options with simple INI files.
You know they adopted a boot loader for this right? It existed before systemd. Regardless an “ease of use bootloader” that comes with a lot of opinions on other things like logging and opaque non-deterministic behaviour? Nah.
- Want to do offline updates? Have any service you want be part of system-update.target, touch /system-update and reboot.
What does this mean?
- Annoyed that you can't have more than 3 dns servers or can't run DNSoTLS or DNSoHTTPS? systemd-resolved has your back.
This has been the horror of many, since the code to do this is so shitty and makes so many assumptions. (Like that it silently fails and makes your application pause, or the more subtle default of using Google’s dns server- which they didn’t pay for and is a weird default in the context of servers- hammering home to me that systemd was for the desktop.
Explains a lot of the design if you frame it that way, looks a lot like the windows subsystem)
- Forget about ntpd or chrony and use systemd-timesyncd is a lightweight standards complaint ntp client.
Why forget about things that work? I don’t understand your reasoning here. Because you like INI files?
- Run all your userspace daemons like offlineimap, tmux, emacs, your dev server, etc. as systemd user services.
This one is fair enough, I used to use supervisord, but that’s very meh- Or there’s the old tmux session that lives forever.
- Manage the permissions, resource usage, and monitor long running jobs with systemd-run.
Same as cgroups again.
- Replace cron with systemd timers that not only have more powerful timespecs, are hooked into the dependency solver, and can be monitored like any other service.
Your argument here boils down to “service integration with corn” because high resolution timers were a thing before systemd. This is solved with other inits (like runit) by making resources available as you request them. Much like xinetd.
- Isolate troublesome 3rd party applications with systemd-portable which are a bit like privileged containers but easier to use.
LXC or in a real pinch, cgroups + chroot.
- Run apps as unprivileged users without having to fill passwd with users and groups just for services with dynamic users.
Polkit. This is what polkit was designed for.
Exactly! I'm not saying that it's unique to systemd, just that it's useful. I expect many next-gen init systems will be implementing many similar features to systemd.
> This is just cgroups, a function of the kernel, not systemd
And Docker resource control is just cgroups too. Doesn't mean it's not much much easier to use. The value of systemd's resource control options is that it comes with a constraint solver and sets up the cgroups to satisfy your desires. If you have many services all with their own caps it becomes very annoying to figure out how to set up the ratios of CPU shares.
> Automount, existed for 15 years at this point.
And it's been super flaky for 15 years. Would you rather edit automount maps or just say, "hey when this path is first accessed, mount it."
> Polkit
Huh? Polkit 100% cannot do this. This is the ability to set and deny Linux capabilities to services. systemd is actually providing something very unique here which as of yet doesn't exist outside systemd.
The userspace tools for capabilities allow you to set them on files so that when you exec them they have (or are denied) the capabilities you set. But what about an interpreted program like python or node? You probably don't want to set CAP_NET_BIND_SERVICE on all node processes, just your web server.
Systemd makes this very easy by starting a service as root, dropping capabilies to match your directives then execing the service. Nothing magic but something very few tools let you do. Someone could write a tool for this but it's doesn't exist anywhere in my repos.
> You know they adopted a boot loader for this right?
Look I know it's gummyboot. Gummyboot is great. Just because it's now systemd-boot doesn't make it any less good. In fact it makes it better since the userspace tooling systemd added greatly improved the experience using it.
> What does this mean?
Downloading updates to apply, rebooting into a minimal environment to apply them, and then rebooting back into your system. It's a very slick implementation.
> Why forget about things that work?
Drastically reduced complexity and attack surface because timesyncd focuses entirely on being a client.
> Same as cgroups again.
Yes they use cgroups under the hood. Tell me how to, from a shell, run an arbitrary process capped at 30% CPU and 128M of memory that's easier than
systemd-run -t -p MemoryMax=128M -p CPUQuota=30% my-process
> LXC or in a real pinch, cgroups + chroot.
Right, but systemd is providing the tooling to make it easy package and run services like this.
> Polkit. This is what polkit was designed for.
Polkit literally cannot do this. Tell me how to make a user $service exist only while $service is running.
Haven't laughed as hard in a while.