Live data from Hacker News

How to Crash Systemd in One Command

agwa.name

171–180 of 193 posts

Re: How to Crash Systemd in One Command

#171
post #169
post #29

Ran as a normal user on debian jessie, and now ssh logins are delayed by 30 seconds. I don't see any other problems yet, but this is a VM host and so leave it running for a while for fun. :)

Ran it on an up to date Ubuntu 16.04 and lost the ability to run any systemctl commands like status, restart, etc. Web server and other system services were still working, but I couldn't `reboot` or `systemctl halt` etc... had to hard reboot the VPS from hosting console. :)

"systemctl reboot --force --force" should work in such cases. The reboot will be executed by systemctl itself.

Re: How to Crash Systemd in One Command

#172
post #127
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…

Are you saying that there are a lot of daemons out there that doesn't fit into systemd's declarative architecture? If so, the daemons could be fixed or systemd could be extended to cater for "not perfectly written" daemons.

On the other hand if the daemon is written by incompetent developers and is doing very stupid stuff then it is a good thing that it doesn't fit. The developers will have an incentive to fix their broken code. And even with systemd it is possible to run arbitrary shell scripts at startup (afaik) which could start the daemon so they aren't totally out of luck.

> For some years now, the Gentoo Project has OpenRC/runscript (specialized shell for init scripts).

But is a scripting language really needed for daemon management? If the answer is no, then a more limited configuration language (systemd's .service files) is better.

Re: How to Crash Systemd in One Command

#174
post #119

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.

I liked upstart!

Upstart also had inscrutable crashing bugs, kind of like what this article describes about systemd, and it didn't even do as much.

Re: How to Crash Systemd in One Command

#175
post #98
post #88

Earlier quoted context omitted.

Mac absolutely can do that, I'm not sure why you think it can't, perhaps it couldn't in the past. I do it almost daily when I come home and plug in my Bose Companion 5 into my Macbook (USB Speakers)

Admittedly, it's been quite some time since I last worked on a Mac. Think 10.6.8 era. It could also have been a borked install as well. But I'm sitting in front of a Win10 install on a Surface 4 Pro, and it can't auto-sink audio.

Windows 10 can _definitely_ do that (I do the exact same thing with bluetooth/wired headsets frequently; I'm "fairly" sure I used to do that on Windows 7 too -- I remember being quite amazed when my Ubuntu machine "finally" caught up and was able to do the same thing.)

In fact, I quite often start music playing on the laptop (chrome/Google Play Music) and then power up my bluetooth headset -- it initially uses eSCO when it routes the audio over (mono) and then switches to A2DP a few seconds later

Maybe the issue is something to do with the SW (chrome/firefox?) you use for GVoice? Or maybe there are some edge cases that I'm not triggering (in particular, a USB headset is effectively a new soundcard and not just an audio sink; I can completely believe windows is flaky with them especially with third party drivers)

Re: How to Crash Systemd in One Command

#176
post #127
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…

I agree on OpenRC. OpenRC is a great, simple, portable solution that really solves the problem without introducing new ones.

What I think is that we see an extreme case of "Not Invented Here". To be honest, OpenRC (at times) was displayed as Gentoo-Only-Project, despite being very portable.

I however want to highlight another general purpose Linux distribution that seems to be kicking along well (ie. not just being an anti-systemd distribution) and uses OpenRC.

Alpine Linux: https://alpinelinux.org/

I have seen it being used and worked with people who have been using it for a while. I never really got into it myself - lack of time being the reason.

Re: How to Crash Systemd in One Command

#177

It seems like it is quite fashionable to hate on systemd, and it seems like systemd is kindof a piece of crap - in some ways. However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. This is open source, if you don't like systemd, if you think it's crap, if you think there are obviously better ways to do it, well, what are you waiting for then? Syst…

The Unix philosophy: Write programs that do one thing and do it well. Systemd doesn't observe the Unix philosophy and that bothers many people.

I'm not that strict on the "unix philosophy". It tends to work, but sure there are exceptions. But if you happen to write something like that does many things, you should also make sure you do every single of those many things well.

What bothers me is that systemd doesn't do that, and that somehow this "unix philosophy" criticism seems to be an excuse/defense for crappy design and code.

Re: How to Crash Systemd in One Command

#178

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 :-)

Sure you can. 5th column of `ls -l` is size; sort can do numerical values

> ls -tl | sort -k 5 -n

Re: How to Crash Systemd in One Command

#179
> The immediate question raised by this bug is what kind of quality assurance process would allow such a simple bug to exist for over two years (it was introduced in systemd 209). Isn't the empty string an obvious test case?

All bugs are terribly easy to spot in hindsight. I don't think it's fair to criticize this one in that fashion. Systemd has lots of pros and cons, but the age of this bug isn't interesting IMO. Its severity is, but that only speaks to the critical need to patch it ASAP.

Re: How to Crash Systemd in One Command

#180
post #153
post #139

Earlier quoted context omitted.

your fork bomb can be mitigated with ulimit

I am not saying that this is not a bug, just that this isn't the problem that the author is making. If you have local access, you probably can do other things if your only objective is to do a DoS.

Your point is covered in the article.

"If you think systemd doesn't need privilege separation because it only parses messages from local users, keep in mind that in the Internet era, local attacks tend to acquire remote vectors. Consider Shellshock, or the presentation at this year's systemd conference which is titled "Talking to systemd from a Web Browser.""

Post reply on HN