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 <mlich...@redhat.com> 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-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > > -- Luke Valenta Systems Engineer - Research
