These are chat archives for CZ-NIC/knot-resolver

11th
May 2018
Robert Šefr
@robcza
May 11 2018 06:38
Could you share any experience on running kresd supervised and scaling? I'm really happy with scaling through -f as it allows communication with all the process using map. However I don't think that -f is viable with supervisor, as supervisor would take care of the topmost process only, however I want all the processes to be supervised.
Configuration sample in the documentation would be really helpful http://knot-resolver.readthedocs.io/en/stable/daemon.html#running-supervised
Vladimír Čunát
@vcunat
May 11 2018 12:41
@robcza for packaging (on systemd distributions) we decided to use templated units (see ./systemd/* in our source for details). That way the processes are handled independently, only sharing a cache. You can still send commands to all relatively easily from outside, as each will have a unix socket and you can e.g. use socat or nc commands to just pipe lua commands into them.
This way of control of the running separate processes should work with any kind of supervisor, I expect.
I've never heard anyone mention using another supervisor, except for @vavrusa.
Petr Špaček
@pspacek
May 11 2018 14:09
@robcza We were kicking with idea to reimplement map() in way which could work with supervised processes but did not get to it yet. If you have some time and want to contribute a patch we can discuss technical details, it should not be that complicated.
Robert Šefr
@robcza
May 11 2018 14:13
@vcunat thanks for sharing. This means we will avoid scaling with -f
@pspacek thank you, we will have to deal with this in several weeks, I will get back to you directly once we are ready to discuss it
Tomas Krizek
@tomaskrizek
May 11 2018 14:14
@robcza I'd recommend to use the upstream systemd implementation for scaling. Basically, you can use systemd to run multiple kresd instances as indepedent processes and they only share cache and the socket. If any of the instances crashes, it doesn't affect any other query or instance and is automatically restarted.
Petr Špaček
@pspacek
May 11 2018 14:16
(Nice property is that you can restart instances one by one so restart is totally seamless.)
Tomas Krizek
@tomaskrizek
May 11 2018 14:17
The use case is described in kresd.systemd(7), but the web documentation is a bit lacking in this regard. It's also useful to use bash expansion to handle these instances, e.g. systemctl start kresd@{1..16}.service will start 16 independent kresd processes
Robert Šefr
@robcza
May 11 2018 14:20
@tomaskrizek seems quite usable, will have to evaluate whether systemd does not clash with our other needs. supervisord could be an option I guess
@pspacek we already use rolling upgrades (though not with systemd) and it works really great
Vladimír Čunát
@vcunat
May 11 2018 15:39
For reference, kresd supports passing open sockets even without systemd via --fd, though I'm not sure when that was last used.