26 Čen
2019
26 Čen
'19
8:34
On 26/06/2019 01.18, Daniel Kahn Gillmor wrote:
It's a performance issue we've seen in our benchmarking attempts. The
issue above could very well be the cause.
After more than a year of actually using socket activation, I no longer
believe these benefits outweight the costs.
On Tue 2019-06-25 18:25:27 +0200, Petr Špaček wrote:
If network configuration is in a config file and you're running multiple
instances, you could restart them sequentially after changing the
network interfaces.
With socket activation, this isn't possible, since the socket can't be
restarted (and thus load the new network configuration) as long as even
one instance is using it. Also, it's quite difficult and unintuitive to
successfully restart the daemons/sockets to use the new configuration,
since it has to be done with system-kresd.slice.
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. 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?
Same as it is now - it falls back to listen on localhost.
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869