26 Čen
2019
26 Čen
'19
1:18
On Tue 2019-06-25 18:25:27 +0200, Petr Špaček wrote:
Up until now we have determined that socket
activation
a) is causing confusion among users,
b) prevents gradual service restarts after network configuration changes,
What does "gradual service restart" mean?
Without socket activation, the sockets in question will be closed during
service restart, leading to failed (rather than queued) queries. With
socket activation, the listening sockets will remain open during service
restart, because the service manager keeps them open.
Note that just reloading the daemon's configuration file on config
change won't be possible if CAP_NET_BIND_SERVICE has already been
dropped (as it should be) -- the process will have to be restarted
entirely, incurring exactly this socket closure.
c) is slow at high QPS (probably for reasons related
to locking inside
socket kernel code).
I'm not sure i understand this last point. Can you point to any
discussion of this in detail?
Are you referring to https://github.com/systemd/systemd/issues/8096 or
something else?
Tentativelly we plan to remove socket activation in
one of future
versions but specific date or release version was not set yet.
I'd be disappointed with this move, if it happens. In addition to
keeping sockets open across a restarted daemon, socket activation is a
useful way to ensure that the daemon stays constrained, and also a way
to keep the system running with a minimal configuration.
Under this scenario, what would kred's logic be about ports to listen on
if it encounters an empty configuration file?
--dkg