5 Čen
2019
5 Čen
'19
17:46
Hi,
I'd like to ask your opinion about knot-resolver's systemd integration -
in particular, about the network configuration which is currently done
via drop-in files for systemd sockets - kresd.socket, kresd-tls.socket,
kresd-doh.socket and kresd-webmgmt.socket. [network-config-doc]
Have you had any issues while trying to configure network interfaces for
kresd?
Do you find the benefits of socket activation worth the extra complexity
of network configuration? (socket activation enables kresd to be
executed under non-priviledged user and the process doesn't require any
extra capabilities)
All the newtork configuration could take place in kresd.conf via
net.listen() [net-listen-exmaple] if we decided to drop the socket
activation feature. However, this would require we start the service
with the CAP_NET_BIND_SERVICE capability, which could be dropped once
kresd binds to the ports.
Any feedback is welcome!
[network-config-doc] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#network-configur…
[net-listen-exmaple] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.net.listen
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
25 Čen
25 Čen
18:25
New subject: network configuration via systemd sockets - feedback?
Hi,
we are eagerly waiting for more feedback, do not hesitate to reply to
mailing list or one of team members using a private channel.
Up until now we have determined that socket activation
a) is causing confusion among users,
b) prevents gradual service restarts after network configuration changes,
c) is slow at high QPS (probably for reasons related to locking inside
socket kernel code).
Tentativelly we plan to remove socket activation in one of future
versions but specific date or release version was not set yet.
Petr Špaček @ CZ.NIC
On 05. 06. 19 17:46, Tomas Krizek wrote:
Hi,
I'd like to ask your opinion about knot-resolver's systemd integration -
in particular, about the network configuration which is currently done
via drop-in files for systemd sockets - kresd.socket, kresd-tls.socket,
kresd-doh.socket and kresd-webmgmt.socket. [network-config-doc]
Have you had any issues while trying to configure network interfaces for
kresd?
Do you find the benefits of socket activation worth the extra complexity
of network configuration? (socket activation enables kresd to be
executed under non-priviledged user and the process doesn't require any
extra capabilities)
All the newtork configuration could take place in kresd.conf via
net.listen() [net-listen-exmaple] if we decided to drop the socket
activation feature. However, this would require we start the service
with the CAP_NET_BIND_SERVICE capability, which could be dropped once
kresd binds to the ports.
Any feedback is welcome!
[network-config-doc] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#network-configur…
[net-listen-exmaple] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.net.listen
26 Čen
26 Čen
1:18
New subject: network configuration via systemd sockets - feedback?
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
8:34
New subject: network configuration via systemd sockets - feedback?
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
1779
days inactive
1800
days old
knot-resolver-users@lists.nic.cz
3 comments
3 participants
participants (3)
-
Daniel Kahn Gillmor -
Petr Špaček -
Tomas Krizek