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

How to Crash Systemd in One Command

agwa.name

Post reply on HN
Print view View original

131–140 of 193 posts

Re: How to Crash Systemd in One Command

#131

Post by geofft »

justinsaccount wrote: post #125
mschuster91 wrote: post #27

Earlier quoted context omitted.

> I don't know why the kernel continues to treat PID 1 so specially By design all processes inherit from PID 1 (directly or indirectly), so you always have an unbroken tree from every process back to PID 1. PID1 aka init is supposed to do bookkeeping (e.g. zombie processing), and if PID1 crashes the bookkeeping records are lost. Because of this, it is better to fail hard, instead of allowing for corrupted process tre…

> Breaking this would basically break compatibility with every existing userland By "Breaking this" you mean "fixing the fact that pid 1 can't crash and restart"? > Because of this, it is better to fail hard It can't be fixed because it would "break compatibility" where that "compatibility" is that the machine should panic? You're not really making a good case for why this can't be changed. Why not * pid 1 exits * ke…

Right. If init opts into it, e.g. by setting some sysctl or something, the kernel changes behavior in the following way:

1. Processes that are reparented to init aren't actually considered children of init for the purposes of the wait() system call. Their ppid still becomes 1, so parent process walks work, but when they exit, the kernel immediately cleans them up.

Zombies still exist in this change, as long as their parent still exists; the only thing that changes is that processes (zombies or not) are not reparented to init when their parent dies. Direct children of pid 1 are not treated specially.

2. When init is about to exit or crash, the kernel turns it into a zombie. It then starts a new init process and reparents the old init to the new one, allowing it to do things depending on the cause of the crash. Direct children of the old init have lost their parent, and are treated like any other parentless process as described above.

3. If execing the new init fails, the kernel panics.

This would be completely backwards-compatible. (I might even argue against 3, to remove all worry about init crashing; since pid 1 is no longer required to do anything, if exec fails, the kernel can just leave pid 1 as a stuck process table entry, let the system continue running, and log something to dmesg so the sysadmin can diagnose the problem and reboot the machine cleanly.)

Re: How to Crash Systemd in One Command

#132

Post by amaranth »

Daviey wrote: post #90
justin_vanw wrote: post #65

Earlier quoted context omitted.

I don't know launchd, but upstart was a piece of crap that didn't even implement it's own documented functionality.

"piece of crap" really isn't fair. It powered many Ubuntu releases and Red hat 6. I liked upstart.

RHEL 6 only supported using upstart in sysvinit compatibility mode, I believe. They didn't actually use any upstart jobs.

Re: How to Crash Systemd in One Command

#133

Post by qwertyuiop924 »

digi_owl wrote: post #128
fapjacks wrote: post #57

Earlier quoted context omitted.

... And also when they can pass the buck to kernel developers, even when it's not a kernel bug.

Reminds me that i ran into an email chain a while back where the kernel devs pondered forking or taking over udev development because they were tired of power games from the maintainer. This was from back before udev became part of systemd btw.

Greg-KH is both one of the original developers on udev and a major force behind systemd. He maintains -stable on the linux kernel.

So either the kerbel devs did take over udev development...

Re: How to Crash Systemd in One Command

#134

Post by bjourne »

pdkl95 wrote: post #112
bjourne wrote: post #93

Earlier quoted context omitted.

> You refuse to look, and thus have clarity. Dude that is not a good argument. What? Should I have to know everything about systemd to comment on one specific part of it? I don't know about alternative init systems either, all I wrote is that for service management: systemd >> SysV. > What is not uniform about the previous service handling implementation in debian? I can't tell you since I don't use Debian. I can tel…

> systemd >> SysV Why are you framing the conversation as if these were the only options? > I don't know about alternative init systems either Oh, so you are speaking from ignorance. I suggest learning about the alternatives such as OpenRC and the management tools such as daemontools, runit, and s6. There are many solutions to these problems, although they may not be supported (by default?) in your favorite distro. J…

Don't be obtuse and don't misunderstand on purpose. It is very clear that I compared SysV vs. systemd in their service/daemon management capabilities and nothing else.

Re: How to Crash Systemd in One Command

#135

Post by justinsaccount »

justin_vanw wrote: post #23
geofft wrote: post #18

Earlier quoted context omitted.

It's baffling to see people insist that that's the UNIX philosophy when the UNIX philosophy has always been about monolithic kernels over microkernels, so "do one thing" is out the window, and about worse-is-better over do-the-right-thing ( https://www.dreamsongs.com/RiseOfWorseIsBetter.html ), so "do it well" is out the window. And the userspace tools don't follow this either. Quoting http://prog21.dadgum.com/139.ht…

Agree 100%. There isn't some magic potion that makes commands compose simply and efficiently.

There is, but it involves using a standardized structured data exchange format instead of formatted text.

powershell solves this by using structured data everywhere at the expensive of not working that well with plain text.

You should be able to run something like

  ls -l | sort +date,-size
but you can't :-)

Re: How to Crash Systemd in One Command

#136

Post by digi_owl »

qwertyuiop924 wrote: post #133
digi_owl wrote: post #128

Earlier quoted context omitted.

Reminds me that i ran into an email chain a while back where the kernel devs pondered forking or taking over udev development because they were tired of power games from the maintainer. This was from back before udev became part of systemd btw.

Greg-KH is both one of the original developers on udev and a major force behind systemd. He maintains -stable on the linux kernel. So either the kerbel devs did take over udev development...

I do wonder if the kernel will split between GregKH and T'so once Torvalds steps down.

BTW GKH was oddly absent in that thread, and the kernel devs ire was aimed at Sievers...

Re: How to Crash Systemd in One Command

#137

Post by geofft »

justinsaccount wrote: post #135
justin_vanw wrote: post #23

Earlier quoted context omitted.

Agree 100%. There isn't some magic potion that makes commands compose simply and efficiently.

There is, but it involves using a standardized structured data exchange format instead of formatted text. powershell solves this by using structured data everywhere at the expensive of not working that well with plain text. You should be able to run something like ls -l | sort +date,-size but you can't :-)

Right, but the same people who keep advocating "do one thing and do it well" also keep advocating "Write programs to handle text streams, because that is a universal interface," and there's no way to handle that sort of things with text streams. A "universal interface," whatever that means, cannot carry that metadata.

Re: How to Crash Systemd in One Command

#138

Post by justinsaccount »

kakwa_ wrote: post #127
bjourne wrote: post #52

Earlier quoted context omitted.

> I'm curious what functionality other OSes had that Linux did not before systemd came along. Uniform daemon/service handling. Just look at the scripts in /etc/init.d (or wherever they are located in your particular SysV init setup). It's a total mess. The rest of what systemd offers I can't comment on because I'm not familiar with it. But it is clear to me that systemd's declarative .service files are a billion time…

The messier part of the old sysinit V was dependency handling, LSB headers are just an horrible hack and do a very poor job at it. However, imho, shell scripts are great for that kind of work. Services come in all sort of shapes, some are proper daemons (fork, cd /, close([stdin, stdout, stderr]) and the rest), some are a little worse to say the least. And more often than not, the later is your super business critica…

> proper daemons (fork, cd /, close([stdin, stdout, stderr]) and the rest), some are a little worse to say the least. And more often than not, the later is your super business critical important app built in house by incompetent developers.

"proper daemons" are broken by design. Perhaps your "incompetent developers" know something that you don't?

https://cr.yp.to/daemontools/faq/create.html

How can I supervise a daemon that puts itself into the background? When I run inetd, my shell script exits immediately, so supervise keeps trying to restart it.

Answer: The best answer is to fix the daemon. Having every daemon put itself into the background is bad software design.

Re: How to Crash Systemd in One Command

#139

Post by rascul »

m45t3r wrote: post #123

You could simple do a DoS attack with a local user using a fork bomb too. It would be even shorter than the command showed in this post blog. So while this is a bug, the author is overreacting just to make systemd look bad.

your fork bomb can be mitigated with ulimit

Re: How to Crash Systemd in One Command

#140

Post by sparewalking »

1_2__3 wrote: post #96
rhinoceraptor wrote: post #26

Earlier quoted context omitted.

I think Systemd is winning because it works (in the overwhelming majority of cases), and no one cares about init systems except the vocal minority.

Can we please just have one OS we use in data centers and servers whose features and development is guided by professionals, not rubes? I'm so sick of people telling me I'm not the target user or some variant thereof. Linux is not OSX or Windows, and not swayed by arguments of the form "most people don't are about that". I do. They should. And the fact that they don't shouldn't result in crappy operating systems.

So what features don't work for you?
Post reply on HN