Re: [chrony-dev] [PATCH] Add support for systemd socket activation

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


I updated the patch and created a MR here: https://gitlab.com/chrony/chrony/-/merge_requests/5. The change should now be much less invasive now. Please let me know what you think!

-Luke

On Tue, Oct 24, 2023 at 10:19 AM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Mon, Oct 23, 2023 at 04:48:22PM -0400, Luke Valenta wrote:
> 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.

Ok, that could be useful.

> 2) More parallelizable boot logic: If any services required chronyd to be
> online before they start then they could be started in parallel with
> chronyd if the sockets already exist. For example, if the command socket is
> pre-initialized, we could start chronyd-wait.service in parallel with
> chrony, removing the `Requires` line at
> https://github.com/mlichvar/chrony/blob/70cdd8b1ef77a5eca4bb41b8b7c42a77b0923ba8/examples/chrony-wait.service#L5

How much time does that save, a millisecond?

> > 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.

You can use the After= ordering. When the service is started (i.e. the
grandparent process of the daemon exited), the sockets are ready.

> > 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.

There could be an array of "reusable" sockets (as a more generic name
in case there are other implementations of this feature), which are
returned by SCK_Open*() when they match the requested address and
port. Other calls would do nothing on these sockets and would be
closed only on exit. If there are no reusable socket, there should be
a negligible impact.

--
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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/