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?
Can anyone give a (brief) explanation as to the background of the controversy?
(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.
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.
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.
You can use pavucontrol without Gnome. Don't know what command-line tools, if any, are available for Pulse Audio.
There is an option to disable upmixing entirely but that triggers at least a couple of bugs. One involves the VU meter indications (shrug). The other causes pulseaudio to emit silence instead of mono streams (fatal).
This bug has been open for over a decade now. At least one patch has been submitted and shrugged off. If you look at the tracker you will see lots of bugs like these where knowledge of the entire system is required to fix them. What seems to have happened is that once the original developers left, some bugs became eternal.
I have not read this carefully enough to fully endorse everything it says, but the main point should be (lack of) modularity.