Thanks for the feedback! Responses in-line.
> If I understand it correctly, this is intended for separated server
> chronyd instances started with -x, right? chronyd is typically started
> at boot to keep the clock synchronized at all times, so I'm not sure
> how useful this would be for most people. I understand you might have
> very different requirements.
Aside from our specific use case (getting a copy of the chronyd service's FDs), these are other use cases I can think of:
1) Zero-downtime reboots: Pass systemd-preinitialized sockets to the main chrony daemon, but still start the daemon at boot time as normal. If the daemon is restarted, the sockets remain open to buffer client requests until the daemon is able to handle requests again.
3) On-demand spawning: Like you mentioned above, activate separated server chronyd instances when the first request comes.
> In that blog post there is an alternative approach mentioned using
> pidfd_getfd. That didn't work for you?
That approach should work, but is a little more involved since there's no event to signal when the app has set up sockets (maybe 'chronyd-wait.service' helps here). Socket activation is a bit more elegant.
> Would it make sense to simply compare
> the local port numbers of sockets provided by systemd with ports of
> to-be-bound sockets and replace the descriptor if they match?
I think this could work, yes! It'll require a little more looping over the available sockets, but shouldn't be very costly in the scheme of things. It might also require moving the SCK_ListenOnSocket functionality into the SCK_OpenTcpSocket call (behind a flag) so we don't call `listen` on an already-listening socket from systemd.
> I think there also would need to be some protection against closing,
> e.g. when issuing the chronyc deny all command. The socket might be
> needed later.
That's a good point. One way to do this would be to update SCK_CloseSocket to leave file descriptors open in the systemd range [SD_LISTEN_FDS_START, FD_LISTEN_FDS_START + LISTEN_FDS).
I'll update the patch to be more minimally-invasive in the short term, and then perhaps it'll be easier to determine if the potential uses justify merging the patch..
-Luke
On Fri, Oct 20, 2023 at 01:31:42PM -0400, Luke Valenta wrote:
> Please consider this patch to add support for using NTP and NTS-KE server
> sockets passed to chrony from the systemd service manager.
>
> For context, we're currently testing out this patch as part of moving
> chrony to our tubular system for routing client traffic to services (
> https://blog.cloudflare.com/tubular-fixing-the-socket-api-with-ebpf/).
If I understand it correctly, this is intended for separated server
chronyd instances started with -x, right? chronyd is typically started
at boot to keep the clock synchronized at all times, so I'm not sure
how useful this would be for most people. I understand you might have
very different requirements.
In that blog post there is an alternative approach mentioned using
pidfd_getfd. That didn't work for you?
The patch seems quite invasive. I'm wondering if it could be better
isolated within the socket code. Would it make sense to simply compare
the local port numbers of sockets provided by systemd with ports of
to-be-bound sockets and replace the descriptor if they match?
I think there also would need to be some protection against closing,
e.g. when issuing the chronyc deny all command. The socket might be
needed later.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
-- Luke Valenta
Systems Engineer - Research