4 ms·

He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: "I have to provide a system that runs reliably and

He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: "I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."

the_mitsuhiko 12y ago
> He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: [Citation needed] From where I stand, systemd is what I always wanted on a server.
- e7620 12y ago
  What feature of systemd did you always wanted on a server?
  - zarvox 12y ago
    I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart. For me, it's a combination of things: 1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph. 2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job! 3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks. 4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them. 5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status. It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.
    - vezzy-fnord 12y ago
      Have you considered running something like monit, alongside Upstart?
      - ominous_prime 12y ago
        I definitely don't want to hide problems with my init systems behind a supervisor that has its own host of problems. The union of those two products does not make a more stable, easy-to-reason-about system. Granted I could choose something better than monit, but then why add another layer to hide brokenness, when we have the capability of doing it correctly in the first place.
    - e7620 12y ago
      systemd is less stable than upstart (and sysvinit, obviusly), "it lacks maturity" says the author. You've had several problems with upstart, but count yourself lucky, certain problems with systemd will take down the whole system, and make it unbootable too! systemd is not reliable, unlike eg daemontools, the developers are busy adding new features and don't care at all about old bugs. They say if you're not using one of the latest kernels, tough luck. So you're continuously debugging systemd "modern innovations" instead of focusing on your product. If you're using Ubuntu, let's hope that by the time it gets adopted, systemd has evolved into a functional, dependable component. I wouldn't bet my product on that, though..
      - RunningDroid 12y ago
        >the developers are busy adding new features and don't care at all about old bugs. What old bugs are you talking about? the only old bugs I can find are fixed or non-systemd bugs that weren't cleaned up >They say if you're not using one of the latest kernels, tough luck. Where recent means at least 3.7, or 3.8 if you want Smack support. >certain problems with systemd will take down the whole system, and make it unbootable too! >you're continuously debugging systemd "modern innovations" instead of focusing on your product. [citation needed] I've been using systemd and systemd user sessions since Arch switched over and the only issues I've come across have been my own fault.
  - Svenstaro 12y ago
    Being able to see what started what, cgroups, which binary produced what output, automatic process restarting is what I like for using on a server. I also like the nice timers output and that I don't need an additional cron or network configuration utility.
sciurus 12y ago
Was there even an argument presented in the section titled 'The invasion of “desktop linux”'? I couldn't find it. Where's the evidence that systemd is making design choices that are driven by desktop linux and detrimental to usage on servers?
- cwyers 12y ago
  There really wasn't. It starts off with: "I’m going to state up front (and people are free to disagree with me) that I believe you cannot provide a distribution of Linux that is both designed for the 'server' and the 'desktop' and provide a product that is worth using on either." I, uh, what? Someone let everybody know that, as I'm pretty sure all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops. Heck, Ubuntu is a very popular server distro[1], and it's certainly a desktop distro. And it's not like sysvinit wasn't used on both the server and the desktop. http://www.openstack.org/blog/2013/11/openstack-user-survey-october-2013/ http://www.openstack.org/blog/2013/11/openstack-user-survey-...
  - derefr 12y ago
    > all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops CoreOS is basically ChromiumOS minus the GUI. It'd be pretty easy to make a "desktop CoreOS" distribution by adding ChromiumOS components.
sp332 12y ago
Why do you "have to" build it on those distros? Why not use a server distro that doesn't even have X let alone GDM?
- copper_rose 12y ago
  The problem is that in many server environments, particularly at scale, the speed of the bootstrap processes of the OS doesn't matter. One of the goals of systemd is to make the bootstrap process faster, which is irrelevant for those (non-desktop) use cases. So you see, systemd is solving problems, and making trade-offs to do it, that just don't matter for the non-desktop use case. I can of course choose not to install gdm, but that doesn't change the fact that systemd was designed (you might say over-designed) with the desktop use case in mind. Because of that, I have to live with those trade offs, even though my use case does not benefit. Since all major Linux distros are deciding to adopt systemd, it will be very difficult to "roll your own" and use something else, especially since the rest of the userland will assume that everyone is doing things the systemd way, this making it even harder to go against the flow.
  - sp332 12y ago
    If you're spinning up a lot of VMs, or paying by the hour or watt, you might care about how fast a server boots. Anyway lots of other init systems do parallel boot, not just systemd. So you don't have to use systemd just to get a fast boot time.
  - cwyers 12y ago
    What tradeoffs is it making for faster boot times that you feel aren't suited to the server?
  - drcube 12y ago
    > Since all major Linux distros are deciding to adopt systemd... Slackware is a major distro. So I expect everyone who opposes systemd to migrate to Slackware, and I'll get even more slackbuilds to browse through on SBO, right?
- VLM 12y ago

the_mitsuhiko 12y ago

> He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: [Citation needed] From where I stand, systemd is what I always wanted on a server.

e7620 12y ago
What feature of systemd did you always wanted on a server?
- zarvox 12y ago
  I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart. For me, it's a combination of things: 1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph. 2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job! 3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks. 4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them. 5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status. It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.
  - vezzy-fnord 12y ago
    Have you considered running something like monit, alongside Upstart?
    - ominous_prime 12y ago
      I definitely don't want to hide problems with my init systems behind a supervisor that has its own host of problems. The union of those two products does not make a more stable, easy-to-reason-about system. Granted I could choose something better than monit, but then why add another layer to hide brokenness, when we have the capability of doing it correctly in the first place.
  - e7620 12y ago
    systemd is less stable than upstart (and sysvinit, obviusly), "it lacks maturity" says the author. You've had several problems with upstart, but count yourself lucky, certain problems with systemd will take down the whole system, and make it unbootable too! systemd is not reliable, unlike eg daemontools, the developers are busy adding new features and don't care at all about old bugs. They say if you're not using one of the latest kernels, tough luck. So you're continuously debugging systemd "modern innovations" instead of focusing on your product. If you're using Ubuntu, let's hope that by the time it gets adopted, systemd has evolved into a functional, dependable component. I wouldn't bet my product on that, though..
    - RunningDroid 12y ago
      >the developers are busy adding new features and don't care at all about old bugs. What old bugs are you talking about? the only old bugs I can find are fixed or non-systemd bugs that weren't cleaned up >They say if you're not using one of the latest kernels, tough luck. Where recent means at least 3.7, or 3.8 if you want Smack support. >certain problems with systemd will take down the whole system, and make it unbootable too! >you're continuously debugging systemd "modern innovations" instead of focusing on your product. [citation needed] I've been using systemd and systemd user sessions since Arch switched over and the only issues I've come across have been my own fault.
- Svenstaro 12y ago
  Being able to see what started what, cgroups, which binary produced what output, automatic process restarting is what I like for using on a server. I also like the nice timers output and that I don't need an additional cron or network configuration utility.

sciurus 12y ago

Was there even an argument presented in the section titled 'The invasion of “desktop linux”'? I couldn't find it. Where's the evidence that systemd is making design choices that are driven by desktop linux and detrimental to usage on servers?

cwyers 12y ago
There really wasn't. It starts off with: "I’m going to state up front (and people are free to disagree with me) that I believe you cannot provide a distribution of Linux that is both designed for the 'server' and the 'desktop' and provide a product that is worth using on either." I, uh, what? Someone let everybody know that, as I'm pretty sure all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops. Heck, Ubuntu is a very popular server distro[1], and it's certainly a desktop distro. And it's not like sysvinit wasn't used on both the server and the desktop. http://www.openstack.org/blog/2013/11/openstack-user-survey-october-2013/ http://www.openstack.org/blog/2013/11/openstack-user-survey-...
- derefr 12y ago
  > all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops CoreOS is basically ChromiumOS minus the GUI. It'd be pretty easy to make a "desktop CoreOS" distribution by adding ChromiumOS components.

sp332 12y ago

Why do you "have to" build it on those distros? Why not use a server distro that doesn't even have X let alone GDM?

copper_rose 12y ago
The problem is that in many server environments, particularly at scale, the speed of the bootstrap processes of the OS doesn't matter. One of the goals of systemd is to make the bootstrap process faster, which is irrelevant for those (non-desktop) use cases. So you see, systemd is solving problems, and making trade-offs to do it, that just don't matter for the non-desktop use case. I can of course choose not to install gdm, but that doesn't change the fact that systemd was designed (you might say over-designed) with the desktop use case in mind. Because of that, I have to live with those trade offs, even though my use case does not benefit. Since all major Linux distros are deciding to adopt systemd, it will be very difficult to "roll your own" and use something else, especially since the rest of the userland will assume that everyone is doing things the systemd way, this making it even harder to go against the flow.
- sp332 12y ago
  If you're spinning up a lot of VMs, or paying by the hour or watt, you might care about how fast a server boots. Anyway lots of other init systems do parallel boot, not just systemd. So you don't have to use systemd just to get a fast boot time.
- cwyers 12y ago
  What tradeoffs is it making for faster boot times that you feel aren't suited to the server?
- drcube 12y ago
  > Since all major Linux distros are deciding to adopt systemd... Slackware is a major distro. So I expect everyone who opposes systemd to migrate to Slackware, and I'll get even more slackbuilds to browse through on SBO, right?
VLM 12y ago