Comment by colin_mccabe | Hacker News Reader

Comment by colin_mccabe | Hacker News Reader

Parent Full thread

systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun.

Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this.

Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.

There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.

Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses.

"Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.

You're really good at copying-and-pasting canned responses from previous comments... throwawayhugerandomnumber

> There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.

If the kernel fucks up the system dies and the kernel is much larger than systemd. Either way most of systemd's functionality is in other subprocesses.

I take issue with the "nobody is forcing you" part. If you want to use Linux, and there are good reasons for it, it will likely be increasingly difficult to avoid systemd. You can argue whether that's "forcing" or just "applying pressure", but it's real.

That said, your other comments resonated with me. I used to fear systemd, and worried that losing the ability to hack on init guts shell scripts meant loosing the power to make my system work for me. I've since discovered that with systemd I don't feel the need to hack on init guts shell scripts like I used to, because it actually manages services intelligently on its own.

> I'm not sure what you mean by "disconnecting from dbus,"

dbus is a dependency of systemd itself, not just of the services that require it.

With kdbus (dbus in the kernel) on its way it is largely moot anyway.

"Disconnecting from dbus" at that point will not be very meaningful.

Moot? Putting dbus in the kernel is demented. Creating a hard dependency between it and a monolithic set of interdependent systemd code is even more demented.

It's like the Linux folks looked at Mac OS X and learned nothing.

Hint: Mac OS X handles more that systemd does, and still does it in a way that maintains separation of concerns between service management, configuration management, logging, and IPC.

If a process dies I would rather it stay dead. Can systemd monitoring and auto-restart be globally disabled?

It's disabled by default, you need to enable it on a per-service basis.

Since there's different needs (I ansolutely really want my bind, httpd, crond and others to restart when they die - I have no desire to log in and do that manually), you just opt in to the auto restarting in the .service file - systemd does not restart anything by default.

Reply on news.ycombinator.com