9 ms·

I still can't find a good reasons why you should use systemd, this things grows out of control and is way out of the initial scope. Upstart was a reasonable re

I still can't find a good reasons why you should use systemd, this things grows out of control and is way out of the initial scope. Upstart was a reasonable replacement for system V I reckon, ...

chatmasta 10y ago
Socket activation is pretty cool. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... If you're hosting a bunch of apps for clients, but not all of them are being used all the time, then you can fit more onto one server by only activating them when they're used. I know Pantheon does this, for example. https://pantheon.io/open-source https://pantheon.io/open-source There has also been some discussion of integrating this functionality into kubernetes: https://github.com/kubernetes/kubernetes/issues/484 https://github.com/kubernetes/kubernetes/issues/484
- jeanpralo 10y ago
  Thats is indeed pretty cool, the whole question is more under the way decisions are beeing taken regardless of what the community says. But I don't really see what this sort of feature has to do in an init process. I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu*. But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)
  - eeperson 10y ago
    I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do. For more details about the advantages of this can be found here[1] and here[2]. [1] - http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html [2] - http://0pointer.de/blog/projects/inetd.html http://0pointer.de/blog/projects/inetd.html
  - SwellJoe 10y ago
    "I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu...." I've heard this argument a bunch, but looking at the actual systemd approach doesn't really convince me that it's the case. There are dozens of binaries, dozens of maintainers, hundreds of contributors. It's comparable to a project with a bunch of parts (think Gnome or KDE only at the systems-level), rather than one big black box that does everything. If there were a single "systemd" program that did all the hundreds of things that the systemd system does, it would be alarming and impossible to maintain. But, it's not. They may be more tightly coupled than some like (I quite like systemd and still find it a little uncomfortably coupled in many places), but that's partially a symptom of doing a bunch of things in new ways. No one built the interfaces needed to do what systemd does in the past, so building systemd took reinventing the universe in some regards. That's actually some of what you're getting when you get "systemd"; things that aren't part of the init system, but existed in some form before and are now being replaced by systemd-provided services. "But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)" That becomes more feasible over time. Right now, there's a lot of moving parts. Another reason for the tight coupling is that the way things work together is still evolving as people learn the shortcomings of this new architecture. systemd is not perfect, but it is a bunch of little pieces working together. A security issue in one of those pieces doesn't necessarily mean we're all fucked any more than a security issue in one part of any of the old systems necessarily meant we were all fucked.
    - digi_owl 10y ago
      Then why is it then being pressed into service across distros?! Why not let it churn on in its own world somewhere out of the way until it settles down and the interfaces are more defined?
      - SwellJoe 10y ago
        Because it would never fit a real world use case, if isn't designed in and for the real world. Software built in a secret lab and trotted out to people after the fact is not the way Open Source works. We build the plane as it flies. It's always been that way in Linux. I'm surprised there's still so much rage about systemd. It's not a bad solution to the problem. I mean, hell, just the move from procedural to declarative for service configuration is huge. The size of that improvement really cannot be overstated.
  - justinsaccount 10y ago
    > I really dislike the idea of having one project handling everything on a box Whatever you do, don't switch to a BSD.
- dv_dt 10y ago
  It's an interesting feature but inetd (or xinetd) did it for a long time decoupled from the boot process. A pro for systemd doing it is maybe consistent nomenclature for service startup, but a con is that it couples in yet another use case to systemd which may lead to a higher risk of security, maintainability problems down the line.
  - SwellJoe 10y ago
    I'm not sure why starting services two different ways would lead to fewer security problems. Seems like a classic example of reducing surface area for attack. One way to start services means one pile of code to audit, one configuration syntax to understand (that it's new is a negative, but that it is declarative rather than procedural in the case of initscripts is a huge win; xinetd is also declarative, so systemd is converging on the known better way to configure starting services), one place to look when figuring out what is running and what is supposed to be running on your system. There have been init bugs in the past. There have been xinetd bugs in the past (and inetd was occasionally notorious with regard to security, though it was usually the services it provided access to rather than inetd itself). There will be bugs in systemd. But, how does consolidating service startup into one project increase the risk?
    - dv_dt 10y ago
      Well for one, systemd hooks to a large number of functions/subsystems that used to be more isolated. Logging, udev, dbus, churn, networking functions, etc. So it's a bit of a judgement call to say it has a larger or smaller attack surface than separating the functions out. I don't know how to really quantify if in the end it ends up more risky one way or another.
- uuoc 10y ago
  And yet, socket activation is nothing new: inetd: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd xinetd: https://en.wikipedia.org/wiki/Xinetd https://en.wikipedia.org/wiki/Xinetd Used in the "olden" days to allow a single server to serve a bunch of services, not all of which are being used all of the time, to a bunch of clients, by only activating them when they are used.
  - chatmasta 10y ago
    Does systemd socket activation offer any advantages over xinetd?
    - eeperson 10y ago
      Yes, it can also support local sockets as well as network sockets.
    - justinsaccount 10y ago
      Afaik something like xinetd forks and execs a copy of the daemon for each connection and communicates over stdin/stdout. This can work for simple services like sshd which fork for each connection anyway, but would never work for something like nginx or redis.
      - Dylan16807 10y ago
        Avoiding extra processes is good, but it's not the end of the world to exec netcat.
      - JdeBP 10y ago
        That is untrue. Read about "wait"/"nowait" (in the xinetd and inetd manuals, for starters).
        justinsaccount 10y ago
        Ah, I must have been thinking of something like https://cr.yp.to/ucspi-tcp/tcpserver.html https://cr.yp.to/ucspi-tcp/tcpserver.html
- rlpb 10y ago
  I find it frustrating that systemd's socket activation API is via library calls and not a protocol. This makes it necessary for separate support in programs to support systemd rather than having a generic mechanism that all init systems might use.
  - digi_owl 10y ago
    Anyone taking bests on said frustration being intentional?
  - hdfahjk 10y ago
    `libsystemd` just provides an implementation of the socket-activation protocol. It is documented and can be implemented easily without libsystemd: after all it's in the end just reading which file descriptors to use as listening sockets from an environment variable.
trengrj 10y ago
After using systemd for a few years on arch linux I no longer despise it. It does have some good features like unifying system jobs and cron jobs, faster boot, journal forward secure sealing (to detect log tampering). I don't like its effective ownership by redhat and its monolithic nature however this can be solved in the long run by forks and standardisation.
- Esau 10y ago
  I do have to admit to being impressed by the boot speed of Arch under Systemd.
- falcolas 10y ago
  > this can be solved in the long run by forks and standardisation. I keep hearing this refrain, but the reality of the situation right now is that Systemd (and the other processes under the same development umbrella) are moving too quickly and are too complex for any fork to ever have a realistic chance. Does there exist a group of people outside of RedHat who understand the internals of the whole thing well enough to even chance a fork?
- JdeBP 10y ago
  The history of uselessd (q.v.) indicates that it cannot be solved by forks.
Esau 10y ago
Systemd is useful; assuming your goal is to turn Linux into Windows. Personally, I would rather use a well crafted Unix system.
thescribe 10y ago
I tried really hard to learn systemd, but I am in the process now of moving to a systemd free distro. It's such a mess.
- edoceo 10y ago
  Gentoo uses OpenRC. It works awesome. I like not being surprised and I like avoiding conversation around systemd cause I don't see it (till I shell into a Debian)
CaptSpify 10y ago
I hate hate HATE systemd. That doeant mean it doesnt have its positive points, however. Example: I love service files. If they would just make everything modular/optional, I wouldnt hate it nearly as much
- brandonmenc 10y ago
  > If they would just make everything modular/optional, I wouldnt hate it nearly as much Do you currently have a need for a piece of systemd that would work better as a standalone component?
  - CaptSpify 10y ago
    Not so much standalone, but being able to substitute other services. Logging and service-management are two issues off the top of my head. I'd love to be able to disable those, and manage them with another service/package.
- justinsaccount 10y ago
  Optional, like the KillUserProcesses option?
  - CaptSpify 10y ago
    Yes, I'm glad they made it optional. I don't like it, but being able to easily turn it off makes it a non-issue to me.

I still can't find a good reasons why you should use systemd, this things grows out of control and is way out of the initial scope. Upstart was a reasonable replacement for system V I reckon, ...

chatmasta 10y ago

Socket activation is pretty cool. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... If you're hosting a bunch of apps for clients, but not all of them are being used all the time, then you can fit more onto one server by only activating them when they're used. I know Pantheon does this, for example. https://pantheon.io/open-source https://pantheon.io/open-source There has also been some discussion of integrating this functionality into kubernetes: https://github.com/kubernetes/kubernetes/issues/484 https://github.com/kubernetes/kubernetes/issues/484

jeanpralo 10y ago
Thats is indeed pretty cool, the whole question is more under the way decisions are beeing taken regardless of what the community says. But I don't really see what this sort of feature has to do in an init process. I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu*. But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)
- eeperson 10y ago
  I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do. For more details about the advantages of this can be found here[1] and here[2]. [1] - http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html [2] - http://0pointer.de/blog/projects/inetd.html http://0pointer.de/blog/projects/inetd.html
- SwellJoe 10y ago
  "I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu...." I've heard this argument a bunch, but looking at the actual systemd approach doesn't really convince me that it's the case. There are dozens of binaries, dozens of maintainers, hundreds of contributors. It's comparable to a project with a bunch of parts (think Gnome or KDE only at the systems-level), rather than one big black box that does everything. If there were a single "systemd" program that did all the hundreds of things that the systemd system does, it would be alarming and impossible to maintain. But, it's not. They may be more tightly coupled than some like (I quite like systemd and still find it a little uncomfortably coupled in many places), but that's partially a symptom of doing a bunch of things in new ways. No one built the interfaces needed to do what systemd does in the past, so building systemd took reinventing the universe in some regards. That's actually some of what you're getting when you get "systemd"; things that aren't part of the init system, but existed in some form before and are now being replaced by systemd-provided services. "But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)" That becomes more feasible over time. Right now, there's a lot of moving parts. Another reason for the tight coupling is that the way things work together is still evolving as people learn the shortcomings of this new architecture. systemd is not perfect, but it is a bunch of little pieces working together. A security issue in one of those pieces doesn't necessarily mean we're all fucked any more than a security issue in one part of any of the old systems necessarily meant we were all fucked.
  - digi_owl 10y ago
    Then why is it then being pressed into service across distros?! Why not let it churn on in its own world somewhere out of the way until it settles down and the interfaces are more defined?
    - SwellJoe 10y ago
      Because it would never fit a real world use case, if isn't designed in and for the real world. Software built in a secret lab and trotted out to people after the fact is not the way Open Source works. We build the plane as it flies. It's always been that way in Linux. I'm surprised there's still so much rage about systemd. It's not a bad solution to the problem. I mean, hell, just the move from procedural to declarative for service configuration is huge. The size of that improvement really cannot be overstated.
- justinsaccount 10y ago
  > I really dislike the idea of having one project handling everything on a box Whatever you do, don't switch to a BSD.
dv_dt 10y ago
It's an interesting feature but inetd (or xinetd) did it for a long time decoupled from the boot process. A pro for systemd doing it is maybe consistent nomenclature for service startup, but a con is that it couples in yet another use case to systemd which may lead to a higher risk of security, maintainability problems down the line.
- SwellJoe 10y ago
  I'm not sure why starting services two different ways would lead to fewer security problems. Seems like a classic example of reducing surface area for attack. One way to start services means one pile of code to audit, one configuration syntax to understand (that it's new is a negative, but that it is declarative rather than procedural in the case of initscripts is a huge win; xinetd is also declarative, so systemd is converging on the known better way to configure starting services), one place to look when figuring out what is running and what is supposed to be running on your system. There have been init bugs in the past. There have been xinetd bugs in the past (and inetd was occasionally notorious with regard to security, though it was usually the services it provided access to rather than inetd itself). There will be bugs in systemd. But, how does consolidating service startup into one project increase the risk?
  - dv_dt 10y ago
    Well for one, systemd hooks to a large number of functions/subsystems that used to be more isolated. Logging, udev, dbus, churn, networking functions, etc. So it's a bit of a judgement call to say it has a larger or smaller attack surface than separating the functions out. I don't know how to really quantify if in the end it ends up more risky one way or another.
uuoc 10y ago
And yet, socket activation is nothing new: inetd: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd xinetd: https://en.wikipedia.org/wiki/Xinetd https://en.wikipedia.org/wiki/Xinetd Used in the "olden" days to allow a single server to serve a bunch of services, not all of which are being used all of the time, to a bunch of clients, by only activating them when they are used.
- chatmasta 10y ago
  Does systemd socket activation offer any advantages over xinetd?
  - eeperson 10y ago
    Yes, it can also support local sockets as well as network sockets.
  - justinsaccount 10y ago
    Afaik something like xinetd forks and execs a copy of the daemon for each connection and communicates over stdin/stdout. This can work for simple services like sshd which fork for each connection anyway, but would never work for something like nginx or redis.
    - Dylan16807 10y ago
      Avoiding extra processes is good, but it's not the end of the world to exec netcat.
    - JdeBP 10y ago
      That is untrue. Read about "wait"/"nowait" (in the xinetd and inetd manuals, for starters).
      - justinsaccount 10y ago
        Ah, I must have been thinking of something like https://cr.yp.to/ucspi-tcp/tcpserver.html https://cr.yp.to/ucspi-tcp/tcpserver.html
rlpb 10y ago
I find it frustrating that systemd's socket activation API is via library calls and not a protocol. This makes it necessary for separate support in programs to support systemd rather than having a generic mechanism that all init systems might use.
- digi_owl 10y ago
  Anyone taking bests on said frustration being intentional?
- hdfahjk 10y ago
  `libsystemd` just provides an implementation of the socket-activation protocol. It is documented and can be implemented easily without libsystemd: after all it's in the end just reading which file descriptors to use as listening sockets from an environment variable.

trengrj 10y ago

After using systemd for a few years on arch linux I no longer despise it. It does have some good features like unifying system jobs and cron jobs, faster boot, journal forward secure sealing (to detect log tampering). I don't like its effective ownership by redhat and its monolithic nature however this can be solved in the long run by forks and standardisation.

Esau 10y ago
I do have to admit to being impressed by the boot speed of Arch under Systemd.
falcolas 10y ago
> this can be solved in the long run by forks and standardisation. I keep hearing this refrain, but the reality of the situation right now is that Systemd (and the other processes under the same development umbrella) are moving too quickly and are too complex for any fork to ever have a realistic chance. Does there exist a group of people outside of RedHat who understand the internals of the whole thing well enough to even chance a fork?
JdeBP 10y ago
The history of uselessd (q.v.) indicates that it cannot be solved by forks.

Esau 10y ago

Systemd is useful; assuming your goal is to turn Linux into Windows. Personally, I would rather use a well crafted Unix system.

thescribe 10y ago

I tried really hard to learn systemd, but I am in the process now of moving to a systemd free distro. It's such a mess.

edoceo 10y ago
Gentoo uses OpenRC. It works awesome. I like not being surprised and I like avoiding conversation around systemd cause I don't see it (till I shell into a Debian)

CaptSpify 10y ago

I hate hate HATE systemd. That doeant mean it doesnt have its positive points, however. Example: I love service files. If they would just make everything modular/optional, I wouldnt hate it nearly as much

brandonmenc 10y ago
> If they would just make everything modular/optional, I wouldnt hate it nearly as much Do you currently have a need for a piece of systemd that would work better as a standalone component?
- CaptSpify 10y ago
  Not so much standalone, but being able to substitute other services. Logging and service-management are two issues off the top of my head. I'd love to be able to disable those, and manage them with another service/package.
justinsaccount 10y ago
Optional, like the KillUserProcesses option?
- CaptSpify 10y ago
  Yes, I'm glad they made it optional. I don't like it, but being able to easily turn it off makes it a non-issue to me.