(I don't agree btw, just giving some info on opinions that others have)
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.htm...
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.
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.
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`.
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.
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.
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.
You also get socket activation, for free.
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.
https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...
At least for smaller tasks like toggling a interface up or down.
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.