4 ms·
"For Internet socket activation, all you have to do is start your daemon the old way, have it bind on the port, and let it sit there idly. If the kernel needs
by astine 12y ago
"For Internet socket activation, all you have to do is start your daemon the old way, have it bind on the port, and let it sit there idly. If the kernel needs the RAM, it will swap the (idle) daemon to disk. If the kernel receives an incoming connection, it will swap the daemon back into RAM so it can handle it. Systemd doesn't need to be involved at all here."
So you want me to patch my Postgres instance to implement this? Or should I just do it in the init script? I guess that's possible, but it requires your sysadmin also be a programmer.
- wmf 12y agoThat's how daemons normally work. The author is obliquely pointing out that socket activation isn't that much of a benefit. Historically, "socket activation" using inetd was common but as hardware got cheaper people gradually dropped inetd in favor of just starting all their daemons at startup.
- astine 12y agoI understand the author's point; he's not being oblique at all. I just disagree. He explicitly claims that the kernel providing socket functionality is enough. But it's not. The example using mkfifo for example, is terrible for instance. It provides no lifecycle management and you'll end up launch multiple versions of a daemon if you accidentally send multiple signals to the pipe. There is a huge difference between "this is technically possible," and this is doable in a way that doesn't have many unforeseen pitfalls. Systemd asks much less of professionals than sysv and that's it's chief selling point.
- marcosdumay 12y agoThe postgres daemon already works that way. Nearly every daemon that listen to a socket works that way (a few don't, surprizingly). That's the point.