11 ms·

I seem to remember that SystemD caused quite a stir for Debian a while back, but I don't remember exatly why. Can anyone give a (brief) explanation as to the b

I seem to remember that SystemD caused quite a stir for Debian a while back, but I don't remember exatly why. Can anyone give a (brief) explanation as to the background of the controversy?

tinco 12y ago
Some people claim SystemD is not in line with unix philosophy. Some think it is bug ridden. Some just feel its adoption was strong armed by political heavy weights. Some feel other solutions might be better. And others believe there was never a problem with the current solution to begin with. (I don't agree btw, just giving some info on opinions that others have)
- falcolas 12y ago
  > Some people claim SystemD is not in line with unix philosophy One example of this interpretation - we can no longer reliably use `netstat -nlp` to determine what process is responding to requests a particular socket. In certain configurations, `netstat -nlp` will show systemd owning the socket, not the process who receives and responds to the process. e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080. To determine who will truly respond, you need to know the proper systemctl incantation, or find the configuration file (there are 8 locations across 3 folder hierarchies where these can live[0]). [0] http://man7.org/linux/man-pages/man5/systemd-user.conf.5.html http://man7.org/linux/man-pages/man5/systemd-user.conf.5.htm...
  - deleted 12y ago
    [deleted]
  - jethro_tell 12y ago
    >you need to know the proper systemctl incantation Isn't this true for all commandline programs? It's a different way to do things in many ways, but this argument doesn't really talk about the merits or pitfalls, only the fact that it's different.
    - falcolas 12y ago
      Well, it's both different and inconsistent. I still have to use netstat for processes who manage their own sockets, but I can't rely on the output for all processes anymore. Also, netstat has existed and worked for more years than I've been a sysadmin. I'm not opposed to learning new things, but this magnitude of change and inconsistency is hard to keep up with.
      - EmanueleAina 12y ago
        But `netstat` was already broken for xinetd-started services. I get that it probably didn't affect you, but it means that `netstat` already had its shortcomings. Now that socket-activated services may see more widespread usage, hopefully someone interested will add to `netstat` the ability to tell who is listening on the socket and not only who opened it (all the data is available in /proc, which netstat is using already). And in the meantime there's always `systemctl list-sockets`.
  - feld 12y ago
    So systemd is doing a reverse proxy for Apache in that configuration? Or is it launching Apache on demand like some sort of advanced inetd? Either way, netstat -nlp isn't lying about who owns the port 80 socket. It's a terrible idea, but the data returned is not incorrect.
    - falcolas 12y ago
      Well, it depends. In some cases, it's opening the file descriptor for a port then giving it to the daemon after the daemon has finished starting up. The service ends up maintaining the socket, but Systemd opened it. In other cases, Systemd acts as an advanced xinitd and start services on demand, which means that Systemd listens and starts a service, but the service does the accept and responds. So... it's hard to say without digging into the systemd configs.
    - EmanueleAina 12y ago
      > So systemd is doing a reverse proxy for Apache in that configuration? Nope, systemd only opens the socket and passes the fd to Apache. > Or is it launching Apache on demand like some sort of advanced inetd? Yes. Since it's already init's job to start services, it does not make any sense to have a different system to start socket-activated services.
  - lucian1900 12y ago
    You're describing binding sockets for other processes, which is a great feature and has been standard practice since forever. You also get socket activation, for free.
    - falcolas 12y ago
      > standard practice since forever Within individual process trees, yes. Across all process trees via the init system, not so much. I agree that it is a very useful thing to do and has been technically possible forever (since spawned processes need to have their inherited file handles over 2 intentionally closed), but it adds a bit of uncertainty and unnecessary coupling when it starts crossing the (admittedly arbitrary) process role boundary. The benefit of faster startup time is negligible for the typical non-desktop. > You also get socket activation, for free. Socket activation has been available for many (10+) years via xinitd, but it is infrequently used for a variety of reasons. For one, it's slow. The time required to spin up a new process to handle the requested information is non-0, particularly in cases where socket activation is most likely to be used (shell scripts, Python/Ruby/Node applications). This is OK for services used only occasionally, but for any frequently used service it is usually unacceptable. Plus, the overhead of keeping an occasionally-used service running in memory and listening to its own socket is typically pretty low, yet it provides the benefit of knowing exactly what is responding to a given socket.
  - qznc 12y ago
    How is a netstat incantation better than a systemctl incantation?
    - Karunamon 12y ago
      Because change for change's sake is often not a good thing? Thats only a couple decades worth of muscle memory thrown down the toilet...
      - qznc 12y ago
        You should unlearn netstat anyways. Its own man pages declares it obsolete. And it was obsolete before systemd appeared. https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...
        digi_owl 12y ago
        Dunno about anyone else, but i prefer ifconfig over ip. At least for smaller tasks like toggling a interface up or down.
        Karunamon 12y ago
        And it uses a completely different output format for all of its commands. Obsolete, maybe, but the net-tools do their jobs admirably.
        BuildTheRobots 12y ago
        Thanks, wasn't aware of that. Though from quick testing, the output of `ss -nlp` seems entirely unreadable compared to `netstat -nlp`.
  - JoshTriplett 12y ago
    > e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080. No, Apache actually listens to port 80, just on a socket created by systemd. systemd opens the TCP listening socket, spawns Apache (potentially on demand when connected to), and passes along the file descriptor for the socket. Apache then treats that file descriptor as though it had opened it itself. Similar to inetd, except that it isn't limited to stdio. That said, since netstat -p shows who opened the socket rather than who is using the socket, socket activation does make it less useful. Given that netstat -p already reads all the necessary information from /proc, it'd be nice to teach netstat to show multiple programs listening on a socket, not just the opener.
matteotom 12y ago
A lot of people don't like systemd for various reasons, ranging from personal to political to technical. The Debian Technical Committee voted that systemd sysVinit needs to be replaced, and that systemd is the best option. Since then, there have been a number of attempts from within Debian to overturn this decision, or at least force Debian to officially support multiple init systems, with the most recent ending with a result of basically "no further discussion is needed."
deleted 12y ago
[deleted]
syoc 12y ago
Developer attitude (keep clicking next in thread) http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html I have not read this carefully enough to fully endorse everything it says, but the main point should be (lack of) modularity. http://www.landley.net/notes-2014.html#23-04-2014 http://www.landley.net/notes-2014.html#23-04-2014
- digi_owl 12y ago
  There was also a "lovely" LMGTFY over on Google+ when systemd grew a DHCP client...
wtbob 12y ago
> Can anyone give a (brief) explanation as to the background of the controversy? Remember the stability, flexibility and reliability that PulseAudio brought to Linux audio? Imagine that in your boot process. I wonder if Lennart Poettering is secretly funded by a consortium of Microsoft, Apple and IBM.
- oblio 12y ago
  Is PulseAudio causing anyone problems these days?
  - ddalex 12y ago
    Yep, to me, all the time. Number one pet peeve - I can't disable mic auto-volume. Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ? Number 3 - everytime I plug my laptop's DisplayPort into a TV (used for presentations here), PA routes the audio automatically over the TV. But when I plug it out, the sounds happly continues into the depths of /dev/null, and I have yet to find a way to re-route it to my headphones without killing the PA daemon. And I can continue. PA works ok only if you if you run Gnome, and you never plug in/out audio devices. It's a horrible software piece, but I'm stuck with it because it's not my priority to write audio daemon replacements.
    - mercurial 12y ago
      > Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ? You can use pavucontrol without Gnome. Don't know what command-line tools, if any, are available for Pulse Audio.
    - anonbanker 12y ago
      make it a priority to install Cadence/JACK on your debian machine, and make PulseAudio it's slave. you'll thank me later.

I seem to remember that SystemD caused quite a stir for Debian a while back, but I don't remember exatly why. Can anyone give a (brief) explanation as to the background of the controversy?

tinco 12y ago

Some people claim SystemD is not in line with unix philosophy. Some think it is bug ridden. Some just feel its adoption was strong armed by political heavy weights. Some feel other solutions might be better. And others believe there was never a problem with the current solution to begin with. (I don't agree btw, just giving some info on opinions that others have)

falcolas 12y ago
> Some people claim SystemD is not in line with unix philosophy One example of this interpretation - we can no longer reliably use `netstat -nlp` to determine what process is responding to requests a particular socket. In certain configurations, `netstat -nlp` will show systemd owning the socket, not the process who receives and responds to the process. e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080. To determine who will truly respond, you need to know the proper systemctl incantation, or find the configuration file (there are 8 locations across 3 folder hierarchies where these can live[0]). [0] http://man7.org/linux/man-pages/man5/systemd-user.conf.5.html http://man7.org/linux/man-pages/man5/systemd-user.conf.5.htm...
- deleted 12y ago
  [deleted]
- jethro_tell 12y ago
  >you need to know the proper systemctl incantation Isn't this true for all commandline programs? It's a different way to do things in many ways, but this argument doesn't really talk about the merits or pitfalls, only the fact that it's different.
  - falcolas 12y ago
    Well, it's both different and inconsistent. I still have to use netstat for processes who manage their own sockets, but I can't rely on the output for all processes anymore. Also, netstat has existed and worked for more years than I've been a sysadmin. I'm not opposed to learning new things, but this magnitude of change and inconsistency is hard to keep up with.
    - EmanueleAina 12y ago
      But `netstat` was already broken for xinetd-started services. I get that it probably didn't affect you, but it means that `netstat` already had its shortcomings. Now that socket-activated services may see more widespread usage, hopefully someone interested will add to `netstat` the ability to tell who is listening on the socket and not only who opened it (all the data is available in /proc, which netstat is using already). And in the meantime there's always `systemctl list-sockets`.
- feld 12y ago
  So systemd is doing a reverse proxy for Apache in that configuration? Or is it launching Apache on demand like some sort of advanced inetd? Either way, netstat -nlp isn't lying about who owns the port 80 socket. It's a terrible idea, but the data returned is not incorrect.
  - falcolas 12y ago
    Well, it depends. In some cases, it's opening the file descriptor for a port then giving it to the daemon after the daemon has finished starting up. The service ends up maintaining the socket, but Systemd opened it. In other cases, Systemd acts as an advanced xinitd and start services on demand, which means that Systemd listens and starts a service, but the service does the accept and responds. So... it's hard to say without digging into the systemd configs.
  - EmanueleAina 12y ago
    > So systemd is doing a reverse proxy for Apache in that configuration? Nope, systemd only opens the socket and passes the fd to Apache. > Or is it launching Apache on demand like some sort of advanced inetd? Yes. Since it's already init's job to start services, it does not make any sense to have a different system to start socket-activated services.
- lucian1900 12y ago
  You're describing binding sockets for other processes, which is a great feature and has been standard practice since forever. You also get socket activation, for free.
  - falcolas 12y ago
    > standard practice since forever Within individual process trees, yes. Across all process trees via the init system, not so much. I agree that it is a very useful thing to do and has been technically possible forever (since spawned processes need to have their inherited file handles over 2 intentionally closed), but it adds a bit of uncertainty and unnecessary coupling when it starts crossing the (admittedly arbitrary) process role boundary. The benefit of faster startup time is negligible for the typical non-desktop. > You also get socket activation, for free. Socket activation has been available for many (10+) years via xinitd, but it is infrequently used for a variety of reasons. For one, it's slow. The time required to spin up a new process to handle the requested information is non-0, particularly in cases where socket activation is most likely to be used (shell scripts, Python/Ruby/Node applications). This is OK for services used only occasionally, but for any frequently used service it is usually unacceptable. Plus, the overhead of keeping an occasionally-used service running in memory and listening to its own socket is typically pretty low, yet it provides the benefit of knowing exactly what is responding to a given socket.
- qznc 12y ago
  How is a netstat incantation better than a systemctl incantation?
  - Karunamon 12y ago
    Because change for change's sake is often not a good thing? Thats only a couple decades worth of muscle memory thrown down the toilet...
    - qznc 12y ago
      You should unlearn netstat anyways. Its own man pages declares it obsolete. And it was obsolete before systemd appeared. https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...
      - digi_owl 12y ago
        Dunno about anyone else, but i prefer ifconfig over ip. At least for smaller tasks like toggling a interface up or down.
      - Karunamon 12y ago
        And it uses a completely different output format for all of its commands. Obsolete, maybe, but the net-tools do their jobs admirably.
      - BuildTheRobots 12y ago
        Thanks, wasn't aware of that. Though from quick testing, the output of `ss -nlp` seems entirely unreadable compared to `netstat -nlp`.
- JoshTriplett 12y ago
  > e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080. No, Apache actually listens to port 80, just on a socket created by systemd. systemd opens the TCP listening socket, spawns Apache (potentially on demand when connected to), and passes along the file descriptor for the socket. Apache then treats that file descriptor as though it had opened it itself. Similar to inetd, except that it isn't limited to stdio. That said, since netstat -p shows who opened the socket rather than who is using the socket, socket activation does make it less useful. Given that netstat -p already reads all the necessary information from /proc, it'd be nice to teach netstat to show multiple programs listening on a socket, not just the opener.

matteotom 12y ago

A lot of people don't like systemd for various reasons, ranging from personal to political to technical. The Debian Technical Committee voted that systemd sysVinit needs to be replaced, and that systemd is the best option. Since then, there have been a number of attempts from within Debian to overturn this decision, or at least force Debian to officially support multiple init systems, with the most recent ending with a result of basically "no further discussion is needed."

deleted 12y ago

[deleted]

syoc 12y ago

Developer attitude (keep clicking next in thread) http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html I have not read this carefully enough to fully endorse everything it says, but the main point should be (lack of) modularity. http://www.landley.net/notes-2014.html#23-04-2014 http://www.landley.net/notes-2014.html#23-04-2014

digi_owl 12y ago
There was also a "lovely" LMGTFY over on Google+ when systemd grew a DHCP client...

wtbob 12y ago

> Can anyone give a (brief) explanation as to the background of the controversy? Remember the stability, flexibility and reliability that PulseAudio brought to Linux audio? Imagine that in your boot process. I wonder if Lennart Poettering is secretly funded by a consortium of Microsoft, Apple and IBM.

oblio 12y ago
Is PulseAudio causing anyone problems these days?
- ddalex 12y ago
  Yep, to me, all the time. Number one pet peeve - I can't disable mic auto-volume. Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ? Number 3 - everytime I plug my laptop's DisplayPort into a TV (used for presentations here), PA routes the audio automatically over the TV. But when I plug it out, the sounds happly continues into the depths of /dev/null, and I have yet to find a way to re-route it to my headphones without killing the PA daemon. And I can continue. PA works ok only if you if you run Gnome, and you never plug in/out audio devices. It's a horrible software piece, but I'm stuck with it because it's not my priority to write audio daemon replacements.
  - mercurial 12y ago
    > Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ? You can use pavucontrol without Gnome. Don't know what command-line tools, if any, are available for Pulse Audio.
  - anonbanker 12y ago
    make it a priority to install Cadence/JACK on your debian machine, and make PulseAudio it's slave. you'll thank me later.