3 ms·
I think it's a little messy to have each of those independently stomping on resolv.conf. There could be race conditions. There could be duplicated code. There c
by asveikau 6y ago
I think it's a little messy to have each of those independently stomping on resolv.conf. There could be race conditions. There could be duplicated code. There could be no one place to disable these things overwriting a handwritten config.
A central piece of code managing that is therefore a good idea. Could be a library rather than a daemon. But a daemon would be one way to resolve races.
Strikes me that this is all a little bit "on the systemd spectrum" though.
- eqvinox 6y agoI'm not suggesting each of these stomps on resolv.conf. I'm suggesting the functionality in the daemon is instead in an executable that just doesn't run permanently, it's just started whenever an event happens and does its thing.
- chousuke 6y agoA daemon that's listening on a socket is not "running permanently". It'll consume approximately no resources until the kernel wakes it up. Having a separate daemon also saves you from having to grant the other daemons credentials to edit the file.
- asveikau 6y agoI do not think this deserves the downvotes. It's absolutely true that with no activity on the socket, it stays off the CPU, and whatever memory use it has could be paged out if needed.
- asveikau 6y agoRight, but as I alluded to, a daemon provides a nice place to synchronize concurrent requests and maybe apply some logic to combine them intelligently. If you had that as an external program you would need a cross process locking scheme and perhaps saving some extra state on disk.