That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either.
> I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH.
The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism.
Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.
The systemd developers are planning on replacing dbus with their own NIH reimplementation, kdbus, soon - complete with its own serialisation format, its own in-kernel IPC framework, and a hard dependency on systemd. (Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.[1] That library currently supports old-style dbus but they're planning to drop support for that, at which point every dbus-using application will require systemd to function. They're also planning to make udev dependent on kdbus[2] in a way that can't be worked around by forking or using old versions, since apps will use the kdbus API to call it directly[3] )
Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.
Have you actually read the mail you're giving as "evidence"?
The last paragraph begins with: "The current idea is that systemd will provide a bridge service, that
offers the current D-Bus socket, and an unmodified libdbus (or an
alternative implementation) can talk to that socket like it talks
today to the dbus-daemon."
Edit:
kdbus is also not a NIH-implementation, in any meaning of the word. It was "invented there", and it also fixes things: it will have much lower latency and overhead than the current userspace D-Bus.
Okay, correction/clarification: it requires everyone to rewrite their code if they want to use kdbus rather than doing old-style dbus calls to the compatibility daemon, which may not be installed by default and is a fairly ugly hack that's probably going away in the future. It needs a bunch of special support code in systemd that's not used for anything else, and the generall expectation seems to be it's a stopgap and most or all dbus consumers will move to kdbus.
Also, technically developers don't have to use systemd's dbus library; apparently Gnome's doing direct calls to the kdbus kernel API instead. That makes it even harder to support systems that don't have kdbus+systemd, of course, but this is Gnome we're talking about.
> it requires everyone to rewrite their code if they want to use kdbus rather than doing old-style dbus calls to the compatibility daemon
Umm... the mere existence of the compatibility daemon makes it pretty clear that one could easily build a system which interfaced with kdbus without changing much of your existing code at all. Your code wouldn't have to be that modular to pull it off.
Honestly, the Linux kernel has, for the longest time kind of been filled with these ad-hoc, efficient IPC mechanisms like netlink. It has severely needed SOMETHING like kdbus, and you can see the key pain points in Linux have already been addressed by other systems using their own proprietary or semi-proprietary mechanism (which invariably happens if you are late to a party that people need addressed immediately).
You need to double fork() in order to ensure that the daemon won't be the controlling owner of the tty once it calls setsid(); i.e. that it will be re-parented to init.
So personally as a sysadmin that occasionally runs daemons from the command line I much prefer a double fork(); I don't want the daemon to exit when I log out.
Both forking and double-forking are completely wrong behavior for supervised daemons run as part of any automated system. Forking makes sense for small systems which lack any automated supervision and where a human admin is responsible for all process starting and stopping, but it's a bug anywhere else. Modern Linux has various methods for working around this bug (like the method of assigning an alternate process for orphaned descendants to be reparented to, which systemd uses, AFAIK), but really any production-quality daemon should provide a non-forking way to start it.
You have to fork, it's the only way to make a new process. Now exactly which process does the fork()ing is, somewhat, academic. Some might argue about the band aid approach of the requirements of parenting and process groups; but that would require leaving POSIX (and hence source compatibility) behind. Allowing any process to set their own parent, process group, or controlling terminal without very strong bounds is dangerous; kind of like having Erlang with mutability, it's possible but it breaks the model (and all the cuspyness that comes with it) and leads to bad juju.
Requiring init to spawn the final daemon process (and hence getting the pid from fork()) is a red herring, any process can get a list of its children and query their proc structure (modulo permissions, but most sane people run init as root).
init should be as small as possible to do only what it is required to do; this is simple anti-fragility at work. The less code and state the better. Feel free to stick your process manager, dependency calculators, and helper daemons in other processes. init should be able to handle something as catastrophic as a SEGFAULT and just execve(/sbin/init) and just carry on (while logging locally and remotely of course).
Yeah, I think we all know why the double fork model exists. It turns out, if fork a daemon from a different process than your login shell, you don't have a problem and you can more reliably track the process...
That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either.
> I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH.
The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism.
Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.