6 ms·

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 weig

by 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.

by tinco 12y ago

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.