Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd is winning the init wars and other things aren't

utcc.utoronto.ca

Post reply on HN
Print view View original

131–140 of 158 posts

Re: Why systemd is winning the init wars and other things aren't

#131

Post by codex »

pdkl95 wrote: post #7

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…

If you have a system made up of small and simple tools, it can only so small and simple things. Imagine designing an airplane this way. It would never get off the ground.

Re: Why systemd is winning the init wars and other things aren't

#132

Post by throwaway092834 »

vidarh wrote: post #77
throwaway092834 wrote: post #5

This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why…

Systemd can run without being pid 1. In fact, systemd can run without being root, and by default systemd now starts a systemd user instance when a user session is started (there's a pam module to do this), or you can run systemd with "--user". So if anyone wants to run systemd as a process monitor like Daemontools, separate from pid 1, they can do so. But there are technical reasons for systemd to run as init: A key…

"But there are technical reasons for systemd to run as init: A key feature is to precisely track whether or not a service is running or not"

This is not true. Tracking a running service doesn't require being init. Any process can do it.

"sysv init can not do this."

Nor should it. Services running under sysV init can, however.

"More importantly, since there's no ordering or dependency control"

Yes, there is -- it's implemented by the rc system. It's crude, but it's also just a bunch of shell scripts and completely pluggable. The systemd logic could trivially be inserted here either in place of /etc/rc, or by something that sits directly under init and drives the rest of the process.

"In practice, while Daemontools for example is well written and as stable as it can be, by virtue of running outside pid 1 it is not immune to the effects of the surrounding system. It can, and does, end up orphaning monitored processes in a variety of circumstances"

Any process can daemonize away from a process manager. systemd adds cgroups for tagging or containing process trees -- this is possible under runit/daemontools and it would only take minor changes to the supervise process to instantiate the cgroup and supervise accordingly.

To be clear: Any process can add cgroup support to track forked children. Solving this problem by adding cgroup support has absolutely nothing to do with becoming init.

"By running as pid 1, systemd is protected against being killed."

No, that is false. There is no such protection -- killing pid 1 is easy. Rather, by running as pid 1 systemd will cause a kernel panic and bring down everything with it.

"By then applying cgroups it can precisely track whether or not what was spawned is still running, even if it forks more stuff. By applying this to the boot process, it can provide this functionality to everything that gets started during boot."

sysV already exports most boot ordering into subprocess. It is trivial to achieve these tasks with systemd as a child of init.

"This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide."

It is true that init doesn't provide these features, nor should it. Your second statement is false -- a common misconception as I've hopefully explained.

If you have any further technical questions about how one CAN perform all these actions as a child of init I would be happy to explain in detail.

Re: Why systemd is winning the init wars and other things aren't

#133

Post by throwaway092834 »

FooBarWidget wrote: post #66
icebraining wrote: post #52

Earlier quoted context omitted.

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.

Re: Why systemd is winning the init wars and other things aren't

#134

Post by throwaway092834 »

mercurial wrote: post #69
icebraining wrote: post #52

Earlier quoted context omitted.

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

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 def…

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/

Re: Why systemd is winning the init wars and other things aren't

#135

Post by throwaway092834 »

vidarh wrote: post #108
icebraining wrote: post #90

Earlier quoted context omitted.

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 admi…

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.

Re: Why systemd is winning the init wars and other things aren't

#136

Post by dschiptsov »

d0 wrote: post #126
dschiptsov wrote: post #119

Earlier quoted context omitted.

I think it is debatable whether or not a relation between words "windows" and "stable" makes any sense.

I disagree. The 400-odd Windows machines under my command are incredibly stable, reliable and well performing. It's not Windows 98 any more.

Do you apply updates? If so, have you ever seen how it breaks functionality of legacy code? Never seen problems with third party tools like Delphi or Java? Never seen Trojan or a virus?

Re: Why systemd is winning the init wars and other things aren't

#137

Post by sparkie »

This article lacks any real substance, and perhaps that embodies my dislike of systemd in general. The demonstrate what I mean, I've modified the parent article, replacing "systemd" with "Windows", "sysv" with "Unix", and "init system" with "operating system", plus a bunch of other title changes to make it coherent, without really modifying the impression of the post: http://pastebin.com/sLsDVBG8 (Don't take it too serious.)

Obviously this is just a bit of humor, but it sounds like something that could've been written in 1990, and the popular choice at the time has made at least a generation of developers and sysadmins suffer, and which some are still suffering from. I think the lesson we can learn is that "ideas" are not unimportant, and should be properly looked at before jumping to binding decisions, because what "solves your problem" now, may cause significantly more in the future.

Re: Why systemd is winning the init wars and other things aren't

#138

Post by d0 »

dschiptsov wrote: post #136
d0 wrote: post #126

Earlier quoted context omitted.

I disagree. The 400-odd Windows machines under my command are incredibly stable, reliable and well performing. It's not Windows 98 any more.

Do you apply updates? If so, have you ever seen how it breaks functionality of legacy code? Never seen problems with third party tools like Delphi or Java? Never seen Trojan or a virus?

Yes we apply updates after testing them. MS11-100 was the only breaking change we've had in 10 years and we picked that up in test no problems at all and knew about it as we read about it before applying the patch in the KB article that accompanied it. Did you know Ubuntu LTS releases shipped buggy and broken MySQL versions multiple times? We caught them in testing. Canonical haven't fixed MySQL in 10.04LTS yet.

No problems with Java, ever in 10 years. We don't use Delphi. Did you know that Debian broke the entire SSH key generation infrastructure for a bit leading to insecure key generation. We regenerate our own keys up front anyway.

Never seen a Trojan or virus because we have proper mitigation at the edge of our network and on critical machines and everything is locked down properly. Did you know about SSH worms -- you know the things that hammer the crap out of every node with SSH on it for the last 5-6 years? We mitigate at the edge (authenticating firewall).

If your opinion of windows is based on such things, you're approaching the problems wrong.

Re: Why systemd is winning the init wars and other things aren't

#139

Post by dschiptsov »

d0 wrote: post #138
dschiptsov wrote: post #136

Earlier quoted context omitted.

Do you apply updates? If so, have you ever seen how it breaks functionality of legacy code? Never seen problems with third party tools like Delphi or Java? Never seen Trojan or a virus?

Yes we apply updates after testing them . MS11-100 was the only breaking change we've had in 10 years and we picked that up in test no problems at all and knew about it as we read about it before applying the patch in the KB article that accompanied it. Did you know Ubuntu LTS releases shipped buggy and broken MySQL versions multiple times? We caught them in testing. Canonical haven't fixed MySQL in 10.04LTS yet. No…

I never seen any statistics about bootnets hosted on rooted Debians. I also remember that in Metasploit framework the number of exploits targeting windows is incomparable larger than Linux related. The last time I made a firewall it was OpenBSD/spark64 based, and I think it is still in production. I never used Debian or Ubuntu as a server. There are Centos or RHEL for that, and I am capable to recompile and repackage any tool I needed.

Sorry, I cannot understand most of mentioned difficulties.

Re: Why systemd is winning the init wars and other things aren't

#140

Post by sparkie »

Xylakant wrote: post #118
theBlackDragon wrote: post #93

Earlier quoted context omitted.

And there you exactly pinpoint the problem. The FLOSS movement used to be about caring about other people and projects. RedHat* and its employees only give a damn about their use-cases and the rest of the "community" can go to hell. Which, of course is a logical stance to take for any corporation, however how easily everyone goes along with it is just appalling. *this, of course, goes for every corporate entity, thou…

> The FLOSS movement used to be about caring about other people and projects. Was it? I thought the primary driver was "I had a problem, this is the fix for my problem, maybe it helps you. I share this solution, you share yours.". Which basically holds true nowadays: Systemd solves Redhats problems. If it solves enough problems for enough people then it will prevail and other people might enhance it to fix their prob…

It would be nice if that held true. The problem isn't that RedHat developed a solution for their own problem, it's that their crowd are incredibly vocal about other people adopting it, even to the point of verbal attacks and attempted character assassinations against people who disagree with their stated aims. And of course, they will never admit publicly that systemd is developed to solve RedHat's problems, but will try to convince people that they have more noble aims, to solve the problems of the wider community. It's rhetoric. If they just dumped the software and let it's technical qualities speak for themselves, there wouldn't be so much drama.
Post reply on HN