Hacker News Reader

Comment by icebraining | Hacker News Reader

I think the point is that you could have the old init system launch systemd, which would then work as it pleased.

Then you have two init systems. That's even more complicated than having only systemd.

We already do. I think most people in this discussion aren't realizing that the current sysV init system is an extremely small pid 1 /sbin/init, and most of the logic in external rc scripts. Moving rc scripts to systemd declarative syntax is fine.

The important part with respect to software architecture is less complexity in pid 1. Subprocesses of init can be safely updated and restarted. More code in init is a real problem -- that's why systemd as pid 1 is controversial.

At the same time, there is a point to be made for having things in a single process - this makes it much easier to ensure that the crucial parts of the init system are available and working.

Can you elaborate? I don't understand this perspective.

I'm not sure this was the point of parent, but anyway, why would you want something like that? It's not like sysvinit has any redeeming feature, and you would still want to have systemd .service files. I could understand an argument like "/bin/systemd does too many things and ought to be split up more", but the rationale for having bad old sysvinit launch /etc/init.d/systemd.sh escapes me. Not to mention that you definitely don't want both systemd and sysvinit to attempt to launch scripts in /etc/init.d, when they don't have a .service...

That is indeed my point. The reason: pid 1 is special on unix. Here's a pretty decent article on the subject: http://ewontfix.com/14/

Say something comes along at that point and kills systemd. Now everything below it is orphaned and has init as it's new parent.

Sysv-init does not know what to do with those processes other than reap zombies.

Now you have a system full of unmonitored processes, just as without systemd, and no standardized way of restarting the services.

This is why systemd needs to run parts of its logic in pid 1 to be most compelling.

You can launch systemd without letting it be pid 1, but you lose functionality it can't provided outside it.

But if systemd was pid 1 and something killed it, you would have a kernel panic. How is that better than a system with a bunch of unmonitored processes? At least with the latter you can safely bring down the system, instead of having a hard crash.

Pid 1 is special - it can't be killed.

It can crash due to bugs it can't handle, or it can voluntarily shut down.

Try it:

  vidarh@opus:~$ sudo kill -9 1
  [sudo] password for vidarh: 
  vidarh@opus:~$

No effect.

In the case of systemd, if it runs into a non-recoverable situation, crash() in core/main.c gets called, which then proceeds to try to create a core dump and spawn a shell as an absolute last resort to give an admin a chance to take corrective action, which is already a step up from your typical init assuming the manage to get the part of systemd that runs as pid 1 (by no means all of systemd runs as pid 1) as stable/bug-free as your usual init.

Of course there's an uncertainty there, and they'll have to prove they can keep that part rock solid or it'll be useless.

There are plenty of ways to kill pid 1. The major concern is simply software error, which is another reason why the current systemd design is poor. But if you'd like a concrete example, go ahead and attach gdb and use your imagination.

Reply on news.ycombinator.com