Hacker News Reader

Comment by falcolas | Hacker News Reader

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

View on HN

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

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

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.

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

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.

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

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.

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.

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

How is a netstat incantation better than a systemctl incantation?

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

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

Dunno about anyone else, but i prefer ifconfig over ip.

At least for smaller tasks like toggling a interface up or down.

And it uses a completely different output format for all of its commands. Obsolete, maybe, but the net-tools do their jobs admirably.

Thanks, wasn't aware of that. Though from quick testing, the output of `ss -nlp` seems entirely unreadable compared to `netstat -nlp`.

Reply on news.ycombinator.com