further reading https://www.man7.org/linux/man-pages/man7/daemon.7.html
The people who keep complaining about it seem more and more like children who just refuse to learn something new and better because they've already stumbled through all the holes it fills.
Systemd apologists always seems to think that anyone not completely in love with systemd, is just refusing to learn something new. Please stop with the stupidity, people have real reasons to hate that shit.
I had no problem with switching to WireGuard, after learning about it, because this is so much better in both use and design than OpenVPN that I have used for 20 years. I had no problem with learning about systemd either, but that is just badly designed software to me.
(And was just wondering if there was any specific thing the original parent wanted to replace.)
Again, was just interested if you had any specific thing you could point to, but elsewhere in the comments I see now a few concrete issues.
You can easily replace timesyncd with any NTP daemon. You can easily replace networkd with any other networking manager. You can easily replace timer units with cron. You can easily forward log messages to a syslog daemon. You can easily replace systemd-boot with grub or any other boot manager.
It should be pretty obvious how baseless the monolithic arguments against systemd are.
Would be funny if people made the same complaint about the various GNU core utils because those are all installed from the same package on most (all?) distros.
Systemd is good init replacement, ok ntp replacement, so-so logging deamon replacement , and shitty DNS resolver replacement.
I like the init part, i could do without everything else.
But the thing I hate the most about it is that if you question any part of it like DNS, you are labeled as a systemd hater.
So I have to find workarounds, like intercepting DNS queries on network level, to fix what used to work before.
And if dnssec ever gets implemented, that wont work either.
Also, dnssec is implemented, and it works.
I wrote whole wall of text but at the end of the day, its not that big of a deal, It's more annoying explaing to customers that they have to talk to their other vendors to fix their configs, so sometimes just network level hack is easier.
[1] In enterprise environment and even some SMB environment its somewhat common (at least here in South EU) that big vendors just drop black boxes to you (usually in a form of vmware image, lately sometimes Docker containers). A lot of them are just stock RH, or Ubuntu with their software. ANd that comes with default fallback to goolge or cloudfalre DNS's
Before systemd, you just needed to set correct DHCP config and it would all just work.
But nowdays distros come with systemd-resolved which usualy has (by deafult) fallback public DNS servers.
That means that boxes suddenly can switch from your DHCP network provided DNS servers (or even static DNS servers) to goolge (or cloudflare,) public DNS server.
Bottom line is, it used to be enough to set DNS server through DHCP (or static ones) that is no longer enough in some situations.
Then, do exactly that? None of the components you're complaining about are mandatory (except for journald, but you can easily forward log messages to a regular syslog daemon).
Often that's not an option and have to create workarounds on network level (for DNS).
Because I might not have a say on what device is running, but if it can't resolve internal systems its my problem.
DNSSEC is going to make my life even more interesting.
"We need a process without a process group, session, controlling terminal and mount point. How to do that? Well, fork two times, setsid, chdir, close all descriptors. Let's call that daemon for short."
If one does not understand what all of this really means, or why all of this is part of a question, who do they blame against learning something new?
Also, if you're not starting from a login session, do you really need to double fork?
Also I just downloaded the recent sources of sshd and it does daemon(0, 0) under the hood, unless -D is passed. ssh.service just runs it with -D, so what's the deal? Does one function call for the case when systemd is not there break some religion?
https://github.com/openssh/openssh-portable/blob/V_8_3/sshd....
It was a technically superior solution murdered by politics.
What's worse was all of the people who were going "why are you moaning? what's wrong? systemd is still an improvement on sysvinit!" as if being better than a bunch of bash scripts held together with bits of sticky tape and string was all the qualification needed to be PID 1.
http://0pointer.net/blog/projects/systemd
(See heading “On Upstart”)
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#172...
And yes, people do erroneously paint it as only a choice between van Smoorenburg init+rc and systemd, as if they were the only two possibilities, when in fact in the Debian Hoo-Hah (for one) it was effectively a choice between systemd, upstart, and OpenRC, nearly all parties agreeing at one point in the proceedings that van Smoorenburg init+rc was last choice, either before or after "further discussion".
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672...
Moreover, I'm not really so sure a couple of those features even belong in an init system.
Debian's decision effectively doomed upstart and led to an init system monoculture. The practical upshot is that no competition for systemd means no pressure to improve. Even for systemd it was a bad decision.
One cannot truly portray this as either "politics" or only about lack of features.
* http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html
* http://jdebp.uk./FGA/unix-daemon-readiness-protocol-problems...
Just write your server as a straightforward process and let the service manager handle this stuff for you. You'll just be confusing it if you don't.
In practice, service managers have been around since 1988.