With systemd (and afaik other service managers) you don't need/should to do all that daemonization dance. The application can run in the foreground, keep any fds open, don't worry about tty etc because the service manager will take care of them for you. As a cherry on top, anything you write on stdout gets automatically forwarded to journald or wherever.
The more I use systemd the more I love it. It simplifies so much, and adds all the little features I see so many projects using custom implementations for.
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.
> 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.
Just disable the parts you don't like on your system. I disable resolved everywhere I can and don't feel the need to go complaining about it. Where are you being labeled a systemd hater? Possibly it's more tone of voice than what you're complaining about.
I do, where I can. But with our clients It's often impossible (due to politics) to control all of the clients on the network, so I can't disable parts I don't like.
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.
Sure if I have access to the host, which I often don't[1].
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
What has systemd-resolved got to do with the fact that you have to use black-boxes? If they had used no DNS management at all and instead just dumped entries in /etc/resolv.conf, you'd be just as SoL as you are now with systemd-resolved. If you can write to /etc/systemd, you can set whatever DNS config you want in the config file for systemd-resolved. I fail to see how our woes with bad software products have anything to do with systemd-resolved.
Most black boxes are just default linux distro with their vendor software on top.
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.
I'm not entirely certain that it is systemd-resolved's fault that the distro maintainers are setting default servers in the config. I'm not disputing that RHEL might, but debian certainly does not, nor any of the distros I've used recently, but I probably have a completely different perspective as I have to deal with more end-user focused distros. I do feel your pain though, DNS config management seems to be incredibly hard. And this fuckery where a OS default setting overrides the DHCP config you're pushing would be incredibly painful.
> I like the init part, i could do without everything else.
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).
I actually thought that systemd is the init part.. Regarding DNS, is the systemd resolver just not advanced/flexible enough? I.e as a desktop user I can't complain about anything, but I don't configure it much either.
As a nitpick, I think "cohesion" and "coupling" are terms coming more from software engineering, I'm not sure they are objects of study in the computer science branch of mathematics.
Which isn't even correct because systemd consists of many individual parts that do their thing and are replacable. But because they all share the "systemd-*" naming pattern people think they're the same piece of software.
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.
Please show independent working implementations of those "replaceable individual parts". AFAIK people who tried to do it found too many obstacles like undocumented or inconvenient API.
Sure, but that's like saying my coffee machine also makes latte and hot chocolate. I guess what I'm asking is: do any of these taste bad, and how? Perhaps the parent had a few of these on his/her mind that could have been listed.
Unix philosophy has a reason. It allows to easily replace components and simplifies testing. AFAIK it's not easy to replace various parts of systemd, it's very monolithic and it does too many things.
> AFAIK it's not easy to replace various parts of systemd, it's very monolithic and it does too many things.
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.
I know the philosophy. What I'm trying to get at is that perhaps the thing that came before was a set of things that didn't quite work together, so now they made something that does.
(And was just wondering if there was any specific thing the original parent wanted to replace.)
I was a fan of upstart. It was simple, it knew how to perform the task it did it, it didn't try to be everything plus the kitchen sink, it worked well and it didn't get its tendrils in everything like systemd does (something that concerns me as it increases the attack surface).
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.
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".
The criticisms levied at upstart there are more about lack of features, not really about overall approach. It's easier to add features than it is to fix a deficient design.
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.
Actually it was about overall approach. Read M. Allberry's further discussions in that bug with Colin Watson, Steve Langasek, and others. Josh Triplett critiques it as well. Cameron Norman's discussion with Nikolaus Rath is also relevant. There were actually quite a lot of technical discussions about the fundamentals of the various architectures. Ian Jackson's and others' discussions about readiness protocols is worth reading, for example.
One cannot truly portray this as either "politics" or only about lack of features.
Why do you stumble up on holes, when all you need to know to make a daemon is described in APUE in detail and in hundreds of books and articles? Making a daemon, either via systemd or a classical way, is learning something new.
"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?
And why, pray tell, must this logic be duplicated (poorly) in every single "service" application? Isn't the UNIX way "do one thing, and do it well"? Isn't the whole "I, the author of the application, will forcefully disregard the environment the user provided to it" against the UNIX spirit of composability? No UNIX application that I know of re-opens the controlling tty as its stdout — that breaks pipes, so is heavily discouraged and nobody does that. Well, "daemonizing" breaks job control/child process control/service managers, and yet people insist on doing it.
Not everyone insists on daemonizing, and not everyone nails their services to whatever popular environment there is. Make it a standard then complain. My point is that doing that also is "learning something new", as opposed to "being a luddite disrespecting our systemd". I'm using systemd and other service managers on all linux instances that I have and with all self-written services, btw, it's just this cool kid stance that bothers.
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?
Forking however many times you want is not going to guarantee that your are spawning a daemon. The process will end up being owned by its nearest sub-reaper, which could in theory still be owned by the initial session.
That implies that daemons always start from a login session and under a process which does this specific trick. That's not true, unless you explicitly wanted them to malfunction.
My point was not that this happens often, but that it is not guaranteed to work (whereas adding your daemon as a systemd service unit is, on systems using systemd).
Also, if you're not starting from a login session, do you really need to double fork?
It is rather sad to see something that was out of date in the 1990s still being circulated today. Even the part about process #1 inheriting orphaned processes is 8 or so years out of date.
Has POSIX ever defined “service manager” as a concept? https://news.ycombinator.com/item?id=11798328 points out that glibc’s daemon(3) function isn’t standard but might be a good place to abstract out “do whatever is appropriate for this distro.”
further reading https://www.man7.org/linux/man-pages/man7/daemon.7.html