7 ms·

I've basically decided systemd isn't for me and have uninstalled it from my systems. The last straw for me was a recent security issue: https://www.agwa.name/b

by new299 10y ago

I've basically decided systemd isn't for me and have uninstalled it from my systems. The last straw for me was a recent security issue: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_... Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to take over from many small single purpose tools seems counter to the UNIX philosophy, and makes it harder to hack on my (mostly desktop/laptop) systems.

ergo14 10y ago
So, what do you use instead?
- antocv 10y ago
  I use OpenRC on my servers, systemd on my desktop/productive-mode laptop. On some servers I use s6 toolset. Those are nice. OpenRC is nice. It gets the work done, its so small, its easy to do things with it, and it has less problems than systemd - which I experience on the desktop. Example, started using networkd for managing networks, because hey why not, and NetworkManager is shit, I had gotten tired of typing wpa-supplicant and dhcpcd commands manually. But then, systemd apparantly takes control over the networking subsystem not only the network interfaces - it changes sysctl flags and doesnt delete after itself when asked to stop - it leaves any addresses and other configuration changes it had done. What!? edit: As all things, systemd-networkd has its place, its just not on a developers laptop, maybe it would be great to have in some kind of cloud environment where you have to configure hordes of machines and virtual machines in them, with networking and networking subsystem configured correctly. Then its nice to have a "do-it-all" tool, but then you should also probably swallow the rest of RedHats output, such as Ansible and look at Project Atomic.
  - ausjke 10y ago
    Alpine Linux uses OpenRC too, the linux preference for Docker these days.
- new299 10y ago
  On debian you can reinstall sysvinit-core.
  - progman 10y ago
    Or you can use Devuan: https://devuan.org https://devuan.org
- bandrami 10y ago
  I'm a fan of Epoch[1], though I don't have it on anything in production right now. On my laptop I use GNU Shepherd[2], because it's what comes with GUIX SD. On my servers I do what I've done for about 2 decades now: I ditch whatever init crap my distribution came with and write a single sh rc script that mounts stuff, starts whatever services I want started, and starts getty. [1]: http://universe2.us/epoch.html http://universe2.us/epoch.html [2]: https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
- semi-extrinsic 10y ago
  I recently replaced Systemd with OpenRC on one of my Arch Linux systems. It was the first time for me, so I was being careful, but still it just took ~60 minutes and I ended up with a more sane system afterwards. My pet peeve about Systemd is the abysmal error logging for services. Usually it will spit out 50-100 lines that offer zero useful information about why something failed. Adding insult to injury, I have noe easy way to add logging of services. If it were a bash script, I could inject "echo $foo > /tmp/service-debug.log" in the script, figure out the problem and fix it. Now I'm stuck with reporting it upstream and likely getting "Unable to reproduce, closing".
usgroup 10y ago
I'm a big fan of the tool-centric Unix Philosophy but I think that the init system is closer to OS than to apps. As another writer mentioned systemd unit files take so much pain out of dependency management, and life-cycle management: all stuff you'd otherwise have to write in code or script. I think it's an elegant and necessary complexity to save us from much uglier and greater complexity.
- Esau 10y ago
  I disagree. But then again, I want a good version of Unix, and not a free competitor to Windows.
  - baldfat 10y ago
    Everything you said was emotional thinking.
    - pjc50 10y ago
      So? All statements of the form "I want .. " are emotional. It's the only sensible way to reason about what you want. There's no "rational" set of preferences that people are obliged to have.
      - baldfat 10y ago
        I want a rational technology based reason why systemd has caused Linux harm. That is not emotional that is a state request from fact based statement.
        parrellel 10y ago
        It is unfortunately a political problem being actively prosecuted with technology. Red Hat would like SystemD to be the init system of record and have - for years now - been subsuming other utilities, daemons, logging, su, etc. in order to make it the obligate choice. Any technical gains from the integrations seem secondary to the control this gives them over the direction of Linux as a whole. This is obvious dirty pool. If they'd gotten where they were on the merits, I think people would be a lot quieter. Beyond the political stupidity, systemd has made itself a single massive and opaque point of failure, especially since it ate logging.
samtoday 10y ago
> Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to take over from many small single purpose tools seems counter to the UNIX philosophy, and makes it harder to hack on my (mostly desktop/laptop) systems. What UNIX philosophy? The biggest UNIX in the world is Linux, which is a monolithic kernel. The UNIX philosophy lives on in apps, but not down that low.
- fao_ 10y ago
  The kernel is monolithic because that design makes sense with respect to speed and the general design of kernels at the time linux was created. I really, really doubt you can say the same about init systems -- especially systemd.
- new299 10y ago
  "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"." https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
  - vetinari 10y ago
    And systemd actually does. It's like complaining that cat or tail are bloated, because coreutils contains so much functionality. Systemd is not a single binary either. It is many binaries, every one of them does its clearly specified job and together they live in single repository - just like coreutils.
    - new299 10y ago
      Well for me it doesn't really seem like that. I want all the things in coreutils. I don't want all the things in systemd, and I don't want unnecessary inter-dependence between them (e.g. udev, journald etc). I find these kinds of discussions a bit strange. I don't want it, it's made my system both less stable and less easily to hack around with. So I'm not going to use it. If you like it, go for it!
bkor 10y ago
That blog has already been discussed various times on Hacker News. The author makes some questionable claims. A security issue is not good, but it's not remotely executable, nor has any relation to being triggered via Twitter. Although this is clarified in the blog, the summary is very misleading. The same author also made a followup blog with even more strange arguments. Saying that systemd security features doesn't matter more or less because applications should be secure by themselves / do that on their own. I'd refrain from forming your opinion solely on blogposts such as these.
- new299 10y ago
  No I didn't form an opinion solely based on this blog. But it made me reconsider my opinion based on my own experience of systemd and the fact that it seems to be very much against the UNIX philosophy (I want a UNIX like system, in particular usecases at least). Did anyone actually think this was a remote exploit that could be triggered via twitter? I certainly was never under that impression.
  - microcolonel 10y ago
    Please explain how: a) systemd violates "the UNIX philosophy". b) "the UNIX philosophy" applies to long-running processes. UNIX daemons have existed for a long time, and they have never been as single-purposed as the shell utilities; so arguably "the UNIX philosophy" doesn't have anything to say about daemons. Secondly, systemd's PID1 has basically only as much functionality in it as makes sense. If they move that functionality to another daemon, it'll be worse.
- deleted 10y ago
  [deleted]
- winter_blue 10y ago
  I read the whole blog post, and I didn't find anything I would disagree with, in it. In my opinion, he makes several good points. > even more strange arguments [...] because applications should be secure by themselves I'll quote him on this: "good programmers recognize the difficulty of writing bug-free software and understand the importance of designing software in a way that minimizes the likelihood of bugs or at least reduces their impact". Design and architectural choices including the choice of programming language have a high impact on the code quality and reliability (incl. security) of a system. No matter how good a programmer you are, there's just a lot additional mental overhead when using an unsafe language like C, as you have to always be on the watch-out for type-safety related bugs, and for memory safety (not accessing invalid references), memory leaks (and always free()ing), and bounds-checking stuff. To quote him further: "Go and Rust are compelling, safe languages for writing the type of systems software that has traditionally been written in C. Systemd is dangerous not only because it is introducing hundreds of thousands of lines of complex C code without any regard to longstanding security practices like privilege separation or fail-safe design" Forget to check array bounds just once, and you might have just created a new security vulnerability. You have to be perfect. Not make a single mistake. Run Valgrind and every code quality other tool, and you still could have missed something subtle. C is an inherently unsafe language, and a poor choice for new projects when alternatives like Rust and Go exist. The other problem is that one should try to avoid building giant monolithic systems. (I think) I read somewhere once that Linus Torvalds said that in hindsight not adopting a microkernel architecture was the biggest mistake he'd made. Quoting the author: "Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." A single PID 1 process shouldn't be doing a million things. Splitting up responsibilities into different specialized programs, running in their own processes would be the way to go. IPC overhead is not sufficiently large to justify creating one giant statically linked executable that does a million things. It's not the Unix philosophy either. > it's not remotely executable, nor has any relation to being triggered via Twitter Maybe he shouldn't have have used the word "tweet" in the title, but it's clear what he's talking about a few sentences in. And, what do you mean it's not remotely executable? Did you try running it? > I'd refrain from forming your opinion solely on blogposts such as these. The author backs up his claims by linking to specific bug-causing lines in GitHub. He makes several solid beautifully explained arguments. It couldn't be more well-written. How many blog posts claiming security holes link to specific lines of code? Your dismissal of his entire blog isn't justified.
op00to 10y ago
Boy, nobody tell this person about :(){ :|: & };: !
- digi_owl 10y ago
  Something that can be handled on any sane config by ulimit, enforced by the kernel.
mi100hael 10y ago
For me it was the fact that it mounts efivarfs read/write which can lead to accidentally bricking your computer, and Pottering's response when concerns were raised was the typically dismissive "we know best" reply which seems to be the standard line of thinking behind systemd. https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
- ars 10y ago
  That is an extraordinarily inaccurate summary of that situation!! Is that really what you got from that? If so you need to do a much better job of understanding what you read.
- kbenson 10y ago
  This was covered in detail here[1], and much of what set people into different camps on the issue is how they interpreted what he said. This was somewhat resolved later, when it was patched in the kernel[2]. My interpretation, for an alternative take, was that Lennart acknowledged it was a problem and should be secured, but noted that there were tools that needed read-write access, so it wasn't as simple as just mounting read-only. He did note how you could mitigate the problem using fstab, but I think a lot of people took his statement that you could do so as the official response and that no fix would be forthcoming, when nothing of the sort was said. In fact, that comment, even though separate from the prior one, had its text encapsulated in parenthesis, which I take as an attempt to indicate it's something he forgot to include in his prior response, and just an addition, so not the definitive answer from the developers on the "solution". Note, the eventual fix to the problem was at a kernel level, not systemd, because systemd didn't design efivarfs, they just use the accepted mechanism for accessing EFI variables on linux, which happens to be a filesystem. Whether you think that's a good choice for an interface or not, or think it was poorly thought out and implemented even if it is a good choice, none of those things have to do with systemd or Lennart, since they are kernel level issues. 1: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 2: https://news.ycombinator.com/item?id=11152880 https://news.ycombinator.com/item?id=11152880
- Fej 10y ago
  Holy crap. I previously thought most of the negativity over systemd was bluster, but this changes that. What the actual fuck?!
GFK_of_xmaspast 10y ago
On ubuntu 14.04 with standard hardware a 100% reliable way for me to crash the x session and send me back to a login screen was to type "emacs" and hit enter. Software has bugs. That's just how it is.
wolfgke 10y ago
> Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to take over from many small single purpose tools seems counter to the UNIX philosophy The same can be said about the Linux kernel.

by new299 10y ago

ergo14 10y ago

So, what do you use instead?

antocv 10y ago
I use OpenRC on my servers, systemd on my desktop/productive-mode laptop. On some servers I use s6 toolset. Those are nice. OpenRC is nice. It gets the work done, its so small, its easy to do things with it, and it has less problems than systemd - which I experience on the desktop. Example, started using networkd for managing networks, because hey why not, and NetworkManager is shit, I had gotten tired of typing wpa-supplicant and dhcpcd commands manually. But then, systemd apparantly takes control over the networking subsystem not only the network interfaces - it changes sysctl flags and doesnt delete after itself when asked to stop - it leaves any addresses and other configuration changes it had done. What!? edit: As all things, systemd-networkd has its place, its just not on a developers laptop, maybe it would be great to have in some kind of cloud environment where you have to configure hordes of machines and virtual machines in them, with networking and networking subsystem configured correctly. Then its nice to have a "do-it-all" tool, but then you should also probably swallow the rest of RedHats output, such as Ansible and look at Project Atomic.
- ausjke 10y ago
  Alpine Linux uses OpenRC too, the linux preference for Docker these days.
new299 10y ago
On debian you can reinstall sysvinit-core.
- progman 10y ago
  Or you can use Devuan: https://devuan.org https://devuan.org
bandrami 10y ago
I'm a fan of Epoch[1], though I don't have it on anything in production right now. On my laptop I use GNU Shepherd[2], because it's what comes with GUIX SD. On my servers I do what I've done for about 2 decades now: I ditch whatever init crap my distribution came with and write a single sh rc script that mounts stuff, starts whatever services I want started, and starts getty. [1]: http://universe2.us/epoch.html http://universe2.us/epoch.html [2]: https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
semi-extrinsic 10y ago
I recently replaced Systemd with OpenRC on one of my Arch Linux systems. It was the first time for me, so I was being careful, but still it just took ~60 minutes and I ended up with a more sane system afterwards. My pet peeve about Systemd is the abysmal error logging for services. Usually it will spit out 50-100 lines that offer zero useful information about why something failed. Adding insult to injury, I have noe easy way to add logging of services. If it were a bash script, I could inject "echo $foo > /tmp/service-debug.log" in the script, figure out the problem and fix it. Now I'm stuck with reporting it upstream and likely getting "Unable to reproduce, closing".

usgroup 10y ago

I'm a big fan of the tool-centric Unix Philosophy but I think that the init system is closer to OS than to apps. As another writer mentioned systemd unit files take so much pain out of dependency management, and life-cycle management: all stuff you'd otherwise have to write in code or script. I think it's an elegant and necessary complexity to save us from much uglier and greater complexity.

Esau 10y ago
I disagree. But then again, I want a good version of Unix, and not a free competitor to Windows.
- baldfat 10y ago
  Everything you said was emotional thinking.
  - pjc50 10y ago
    So? All statements of the form "I want .. " are emotional. It's the only sensible way to reason about what you want. There's no "rational" set of preferences that people are obliged to have.
    - baldfat 10y ago
      I want a rational technology based reason why systemd has caused Linux harm. That is not emotional that is a state request from fact based statement.
      - parrellel 10y ago
        It is unfortunately a political problem being actively prosecuted with technology. Red Hat would like SystemD to be the init system of record and have - for years now - been subsuming other utilities, daemons, logging, su, etc. in order to make it the obligate choice. Any technical gains from the integrations seem secondary to the control this gives them over the direction of Linux as a whole. This is obvious dirty pool. If they'd gotten where they were on the merits, I think people would be a lot quieter. Beyond the political stupidity, systemd has made itself a single massive and opaque point of failure, especially since it ate logging.

samtoday 10y ago

> Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to take over from many small single purpose tools seems counter to the UNIX philosophy, and makes it harder to hack on my (mostly desktop/laptop) systems. What UNIX philosophy? The biggest UNIX in the world is Linux, which is a monolithic kernel. The UNIX philosophy lives on in apps, but not down that low.

fao_ 10y ago
The kernel is monolithic because that design makes sense with respect to speed and the general design of kernels at the time linux was created. I really, really doubt you can say the same about init systems -- especially systemd.
new299 10y ago
"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"." https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
- vetinari 10y ago
  And systemd actually does. It's like complaining that cat or tail are bloated, because coreutils contains so much functionality. Systemd is not a single binary either. It is many binaries, every one of them does its clearly specified job and together they live in single repository - just like coreutils.
  - new299 10y ago
    Well for me it doesn't really seem like that. I want all the things in coreutils. I don't want all the things in systemd, and I don't want unnecessary inter-dependence between them (e.g. udev, journald etc). I find these kinds of discussions a bit strange. I don't want it, it's made my system both less stable and less easily to hack around with. So I'm not going to use it. If you like it, go for it!

bkor 10y ago

That blog has already been discussed various times on Hacker News. The author makes some questionable claims. A security issue is not good, but it's not remotely executable, nor has any relation to being triggered via Twitter. Although this is clarified in the blog, the summary is very misleading. The same author also made a followup blog with even more strange arguments. Saying that systemd security features doesn't matter more or less because applications should be secure by themselves / do that on their own. I'd refrain from forming your opinion solely on blogposts such as these.

new299 10y ago
No I didn't form an opinion solely based on this blog. But it made me reconsider my opinion based on my own experience of systemd and the fact that it seems to be very much against the UNIX philosophy (I want a UNIX like system, in particular usecases at least). Did anyone actually think this was a remote exploit that could be triggered via twitter? I certainly was never under that impression.
- microcolonel 10y ago
  Please explain how: a) systemd violates "the UNIX philosophy". b) "the UNIX philosophy" applies to long-running processes. UNIX daemons have existed for a long time, and they have never been as single-purposed as the shell utilities; so arguably "the UNIX philosophy" doesn't have anything to say about daemons. Secondly, systemd's PID1 has basically only as much functionality in it as makes sense. If they move that functionality to another daemon, it'll be worse.
deleted 10y ago
[deleted]
winter_blue 10y ago
I read the whole blog post, and I didn't find anything I would disagree with, in it. In my opinion, he makes several good points. > even more strange arguments [...] because applications should be secure by themselves I'll quote him on this: "good programmers recognize the difficulty of writing bug-free software and understand the importance of designing software in a way that minimizes the likelihood of bugs or at least reduces their impact". Design and architectural choices including the choice of programming language have a high impact on the code quality and reliability (incl. security) of a system. No matter how good a programmer you are, there's just a lot additional mental overhead when using an unsafe language like C, as you have to always be on the watch-out for type-safety related bugs, and for memory safety (not accessing invalid references), memory leaks (and always free()ing), and bounds-checking stuff. To quote him further: "Go and Rust are compelling, safe languages for writing the type of systems software that has traditionally been written in C. Systemd is dangerous not only because it is introducing hundreds of thousands of lines of complex C code without any regard to longstanding security practices like privilege separation or fail-safe design" Forget to check array bounds just once, and you might have just created a new security vulnerability. You have to be perfect. Not make a single mistake. Run Valgrind and every code quality other tool, and you still could have missed something subtle. C is an inherently unsafe language, and a poor choice for new projects when alternatives like Rust and Go exist. The other problem is that one should try to avoid building giant monolithic systems. (I think) I read somewhere once that Linus Torvalds said that in hindsight not adopting a microkernel architecture was the biggest mistake he'd made. Quoting the author: "Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." A single PID 1 process shouldn't be doing a million things. Splitting up responsibilities into different specialized programs, running in their own processes would be the way to go. IPC overhead is not sufficiently large to justify creating one giant statically linked executable that does a million things. It's not the Unix philosophy either. > it's not remotely executable, nor has any relation to being triggered via Twitter Maybe he shouldn't have have used the word "tweet" in the title, but it's clear what he's talking about a few sentences in. And, what do you mean it's not remotely executable? Did you try running it? > I'd refrain from forming your opinion solely on blogposts such as these. The author backs up his claims by linking to specific bug-causing lines in GitHub. He makes several solid beautifully explained arguments. It couldn't be more well-written. How many blog posts claiming security holes link to specific lines of code? Your dismissal of his entire blog isn't justified.

op00to 10y ago

Boy, nobody tell this person about :(){ :|: & };: !

digi_owl 10y ago
Something that can be handled on any sane config by ulimit, enforced by the kernel.

mi100hael 10y ago

For me it was the fact that it mounts efivarfs read/write which can lead to accidentally bricking your computer, and Pottering's response when concerns were raised was the typically dismissive "we know best" reply which seems to be the standard line of thinking behind systemd. https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402

ars 10y ago
That is an extraordinarily inaccurate summary of that situation!! Is that really what you got from that? If so you need to do a much better job of understanding what you read.
kbenson 10y ago
This was covered in detail here[1], and much of what set people into different camps on the issue is how they interpreted what he said. This was somewhat resolved later, when it was patched in the kernel[2]. My interpretation, for an alternative take, was that Lennart acknowledged it was a problem and should be secured, but noted that there were tools that needed read-write access, so it wasn't as simple as just mounting read-only. He did note how you could mitigate the problem using fstab, but I think a lot of people took his statement that you could do so as the official response and that no fix would be forthcoming, when nothing of the sort was said. In fact, that comment, even though separate from the prior one, had its text encapsulated in parenthesis, which I take as an attempt to indicate it's something he forgot to include in his prior response, and just an addition, so not the definitive answer from the developers on the "solution". Note, the eventual fix to the problem was at a kernel level, not systemd, because systemd didn't design efivarfs, they just use the accepted mechanism for accessing EFI variables on linux, which happens to be a filesystem. Whether you think that's a good choice for an interface or not, or think it was poorly thought out and implemented even if it is a good choice, none of those things have to do with systemd or Lennart, since they are kernel level issues. 1: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 2: https://news.ycombinator.com/item?id=11152880 https://news.ycombinator.com/item?id=11152880
Fej 10y ago
Holy crap. I previously thought most of the negativity over systemd was bluster, but this changes that. What the actual fuck?!

GFK_of_xmaspast 10y ago

On ubuntu 14.04 with standard hardware a 100% reliable way for me to crash the x session and send me back to a login screen was to type "emacs" and hit enter. Software has bugs. That's just how it is.

wolfgke 10y ago

> Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to take over from many small single purpose tools seems counter to the UNIX philosophy The same can be said about the Linux kernel.