Systemd can do things that were not relevant 20 years ago.
Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option?
> Is that really true
Yes
Why?
What is the appeal of writing immensely long, fragile shell scripts?
Having to wrap them in various monitoring and logging daemons
Having to have different ones for every distro you want to support with your software
Is this something that is truly a productive use of your time? Putting aside the question of if systemd is "good" or not. Is the current sysvinit system truly "good enough" and not in need of change?
Something having been used for decades certainly doesn't mean that it's optimal and shouldn't be changed, but it does strongly suggest that it's good enough.
For me it's relative and a case of "the devil I know". I actually prefer BSD-style init to sysvinit, but I've used the latter for ~20 years. I'm aware that traditional init systems may not meet the requirements of certain users (eg. those who run very large server installations), but for my simple use case (small servers and workstations) they do the job.
I'm not against change per se; I'm running Void (with runit) on one of my systems, and the desktop I'm using to post this runs OpenBSD.
On the other hand, systemd is too big, takes on too much responsibility (really I need a system to retrieve logs in it? or a way to run local dns?).
Since last update on my ubuntu desktop I can't get dns to work from DHCP, I need to overwrite /etc/resolv.conf with correct nameservers after each restart (BTW. Why would anyone think that running local DNS is a good default option - I see `nameserver 127.0.0.1` in the overwritten file).
And the second one on Debian on my laptop, when I run VPN (openconnect) name resolution fails, and I need again - ovewrite resolv.conf.
I didn't have such problems with sysvinit.
systemd is so controversial that I'm astonished why it is used in any distro.
How do you encode service dependencies? If a service dies, what happens to services relying on it on your system?
Also, maybe I'm just lucky (or using popular hardware, or something), but services on my machine don't just randomly die for no reason. NetworkManager, sshd, etc all seem pretty well-written and stable.
It depends on the service in use and how is it defined. I have an embedded system in production, which have quite a complex graph of dependencies, some of which should be restarted on sudden death of others, some of which should persist anyways.
Needless to say that systemd provides an incredible, robust and easy way of solving that, I had to write just a few 10-line long unit files for in-house software and use standard units provided by standard daemons.
>imagine if systemd suddenly killed and restarted your browser
Because your browsed doesn't rely on them. But my web interface definitely depends on NetworkManager, because it speaks to it via d-bus.
Which is a good thing! Even though my browser uses/"depends on" audio, I still don't want systemd to restart it without warning if PulseAudio dies.
It generally is, really. Resolving DNS servers are, for some reason, apparently much more difficult to run properly than authoritative ones. It's been a trend in many consulting gigs, where there are periodic outages due to reliance on some resolving DNS server somewhere that is overloaded, having a gray failure, or just generally down. It's also been a trend in basically every consumer ISP I've used over the past several decades - running my own resolving DNS servers has cut out on the outages I have experienced quite a lot.
I could probably achieve the same affect by just pointing everything at 4.2.2.1 or 8.8.8.8 or whatever, but I keep more control over my browsing habits by caching most results locally, have lower latency on lookups, etc. In large environments the gains can be even larger.
I prefer running more centralized resolving nameservers on the LAN for clients, but if you don't have that, then you're still gaining quite a bit running it on the local machine.
(and by no means am I a fan of systemd - I just think that this is a fairly sane default)
Check your VPN config, it should update systemd settings automatically when connecting/disconnecting.
Well, considering quite a few distros had already replaced sysvinit with upstart prior to systemd, obviously we have multiple options besides sysvinit. There's also options such as openrc, which will let you make use of whatever you want for pid 1, and manage services elsewhere.
In general, whether or not replacing systemd with something besides sysvinit/upstart is a practical option depends on how reliant you are on packages provided by an upstream distro or 3rd party. It isn't particularly hard to just swap init systems on several distros - debian included - but there are varying levels of tie-in with provided packages.
If you're building all of your required packages with a CI/CD pipeline and deploying with containers based on a minimal linux distro, you could relatively easily use a myriad of systemd and sysvinit alternatives. If you're just deploying on RHEL or Ubuntu VMs and doing yum/apt install to get your software, it's relatively more difficult.
Personally, I think sysvinit needs to be relegated to the annals of history. But I also have been bitten in production many times by systemd bugs, which due to the more... integrated... nature of systemd and it's components have been more trying to troubleshoot and have resulted in longer periods of problematic behavior, increased system level outages, and other headaches. Back when I worked with Solaris, I loved SMF - not so much the XML portion of it, but it worked well, was leaps and bounds ahead of sysvinit in usability in features, and didn't manage to induce nearly as many problems in my production environments as systemd has. And this isn't the first project I've wasted hundreds of hours of my life troubleshooting from the key systemd maintainers. My general experience with their projects has left the impression that they are not nearly as concerned at making their software bug-free as they are chasing features and use cases that interest them. Which is fine - they're welcome to write whatever software they want and prioritize things however they want.
My hope is that some other init system which recognizes the fact that it's no longer the 80s receives traction. Init scripts are awful, and no one should be writing them in this day and age, but I would prefer a system that only has a subset of systemd features but is instead focused on maintaining airtight code quality for those features. I don't need the vast majority of the features and services offered in today's systemd suite, and I don't want to suffer from the cost that all of those diversions extract on the core functionality. Crib the good parts, keep a high quality bar, and make sure a feature is likely to produce high positive impact before investigating resources in delivering it. Which is, I know, quite a lot to ask.
Yes, "horses for courses" as stated in the post you're replying to. I don't require systemd, but I have no problem with it existing for those who do need it. I do have a problem with the idea that something that works better for me should be removed merely because it's "old".
What do other init systems do that systemd doesn’t?
It might have had a controversial history, but it’s here to stay. Just deal with it.
If they're script based, they allow lower level troubleshooting and modification without having to recompile.
systemd is written in a language that is easier than shell to get right, and it's capable of things very few script-based init systems are capable of, so in practice it's very rare that the code of the init system itself needs to be debugged. It's basically rock solid compared to sysv-rc.
You might regard C as easier than shell to get right (that's debateable), but systemd has many many more lines of source code than sysvinit. Good luck debugging it at source code level on a remote system if that "very rare" event occurs.
Going binary is like going back to Windows. If systemd was how Ubuntu worked 15 years ago, it's likely I wouldn't have seen the advantage and wouldn't have bothered switching.
Skip an opaque spaghetti-code declarative-to-imperative compilation step that I have to debug at 3am.
[0] https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/