My main problem with systemd is the lack of robustness in its design and implementation. It seems like an attempt at reimplementing Solaris' SMF, but poorly. Even the SMF itself could probably be called 'overengineered', however, it is certainly a more sophisticated, less monolithic design that provides a much higher level of fault-tolerance.
systemd is basically a huge pile of modules compiled into the PID 1 init process. The problem with that is, that if PID 1 dies, the system stops (e.g., kernel panic).
On Solaris, a small basic init process starts the SMF master restarter (svc.startd), which is responsible for starting, stopping or restarting the other components of the SMF as well as all services managed by the SMF. If a component of the SMF fails (maybe it just dies/SEGVs, or say, you kill it, cause it hangs), the master restarter will respawn it. Even if the master restarter goes south, that small basic init process will respawn the entire SMF, and you're still up and running.
Then, let's take a look at the implementation of systemd:
static int socket_spawn(Socket *s, ExecCommand *c, pid_t *_pid) {
_cleanup_free_ char **argv = NULL;
...snip...
r = socket_arm_timer(s);
if (r < 0)
goto fail;
...snip... (function call with lots of undocumented arguments, returning r)
if (r < 0)
goto fail;
r = unit_watch_pid(UNIT(s), pid);
if (r < 0)
/* FIXME: we need to do something here */
goto fail;
*_pid = pid;
return 0;
fail:
s->timer_event_source = sd_event_source_unref(s->timer_event_source);
return r;
}
Actual code from systemd-216; see full source at src/core/socket.c
Most of the systemd source code looks like this.
Virtually no comments; lots of single-letter variable names, confusingly similar names like "_pid" and "pid"; throwing 'int' return codes back up five calls, where the original caller cannot even remember what all the possible return codes might be (how about enum?); lots of arbitrary goto- and return-jumps out of the middle of somewhere; lots of break and continue, even mixed in the same loop; even substantial amounts of three-star-programming (never heard of it? google it, it's funny); etc.
Okay, I have to add, that the code of lots of the "good, old, reliable UNIX codebase" does not look a lot better (and upstart, or even the Linux kernel, are guilty of at least some of the same bad coding habits). But we have paid the price for writing code that way numerous times, and it seems we did not learn from history.
Coding like that is probably okay if you're writing a nice, little command line utility. But if systemd wants to be THE new init system, it had better look like it had been written by the inventor of reliability engineering.
Right now, the systemd source looks like it violates virtually all of the best practices for writing reliable code. Take a look at what those people who know their craft recommend - e.g., the Federal Aviation Association, European Space Agency, Lockheed Martin's avionics section, etc. - and compare that to systemd's source.
It's like a disaster waiting to happen.
