Comment 18 for bug 1589780

With discussions ongoing a new option came up.

Upstream doesn't really see the case for -X yet, but we can't maintain it reasonably for what we need it without that upstream. (we can do it in shell wrappers, but that is a huge maintenance debt and fails as it can never fully test if it can adjust the time the way chrony would).

Here a log of the discussion that came up with a new two-service model based on OnFailure.
That needs some experiments if it could work for us.

[16:03] <cpaelzer> mlichvar: ping, on the discussion around -X - would you have time to discuss that?
[16:03] <mlichvar> cpaelzer: sure
[16:04] <cpaelzer> mlichvar: I just replied to your last mail - but I'll happily try to outline the use-case in more ways until we found something we can agree upon
[16:04] <cpaelzer> currently I really think it is a needed use case in addition to "-x or not -x"
[16:05] * mlichvar is reading the email
[16:05] <cpaelzer> to some extend it is due to the lack of a split between client/server - the service covers both
[16:05] <cpaelzer> I essentially want -X to be "be a server for sure, and a client if you can"
[16:05] <cpaelzer> maybe these words are better?
[16:06] <cpaelzer> waiting until you have read the mail ...
[16:06] <mlichvar> the trouble that I have with this, is that the client part is much more important the the server part
[16:07] <mlichvar> I think enabling -X by default would be a mistake
[16:07] <mlichvar> people and applications will see a service running, from chronyc everything looks as expected, but the clock is not synchronized
[16:08] <cpaelzer> I see that, which is part why I wrote "discussions are ongoing" and I'm leaning to the "-X is not the default"
[16:08] <cpaelzer> but
[16:08] <cpaelzer> I have applications dragging chrony in that need just this behavior
[16:08] <mlichvar> then there is a question when it would make sense to use -X, but not -x
[16:08] <mlichvar> any examples?
[16:09] <mlichvar> maybe there should be two different services? one for client and optionally a server, and another for server only?
[16:09] <cpaelzer> for said application above, they want to have the server portion work for sure (which -X gives them) but they also want the client part if they can get it (that only -X provides, -x won#t do that)
[16:10] <r3> kenyon: I've changed it so it now allows IPv6 addresses. Tested it too - let me know if it works for you?
[16:10] <cpaelzer> mlichvar: yeah I mentioned the two service approach a while ago I think
[16:11] <cpaelzer> but I think you told me that they are usually tightly interlocked
[16:11] <mlichvar> -x/-X breaks the chrony-wait.service, which could be a problem
[16:11] <mlichvar> and everything that just checks if the service is running and/or chronyc reports "synchronized"
[16:11] <cpaelzer> mlichvar: for the last mention of server/client split https://<email address hidden>/msg01816.html
[16:12] <cpaelzer> mlichvar: but that lack of chrony-wait is the drawback of -x already, -X would inherit that in the case it can't sync the clock
[16:13] <mlichvar> yes, that would be a reason to have a separate service
[16:13] <mlichvar> they would never run both at the same time
[16:14] <mlichvar> so, the applications require something listening on port 123?
[16:15] <cpaelzer> the application wants time to be served - so yeah it wants "something on 123"
[16:17] <cpaelzer> it e.g. essentially wants to control a rack full of nodes and them in sync among each other, therefore the "serving" part - it would apprciate if the local clock is synced if it is possible
[16:17] <cpaelzer> that is the -X use case
[16:17] <cpaelzer> mlichvar: do you have a secondary service in mind that runs with -x always?
[16:17] <cpaelzer> and conflicts with the normal service
[16:18] <cpaelzer> or a real two service solution that would both run independently, one as client one as server?
[16:18] <mlichvar> conflicting services
[16:18] <mlichvar> maybe using the OnFailure= option in the unit file?
[16:19] <mlichvar> what exactly it means "it would apprciate if the local clock is synced if it is possible" ?
[16:20] <mlichvar> applications generally expect the clock to be synchronized, but if it is ok to not have it synchronized, what difference will it make?
[16:21] <mlichvar> in my expecience containers usually don't have the capability and the clock needs to be synchronized on the host, or in a special container
[16:22] <cpaelzer> yes to sync on the host mostly
[16:22] <cpaelzer> until time namespaces are a thing
[16:22] <cpaelzer> mlichvar: for "synced if it is possible": they are afraid to set "-x" in every case, but face the issue that without they won't get the server in the cases time can't be adjusted
[16:22] <cpaelzer> OnFailure is an interesting thought
[16:23] <cpaelzer> so we could have a general service (as it is) and run it with "-x" if it failed without
[16:23] <cpaelzer> hmm
[16:23] <cpaelzer> it is somewhat bad by making things very hard to check as the services won't have the same name
[16:24] <cpaelzer> "do I need chrony or chrony-fallback for my systemctl here"
[16:24] <cpaelzer> which again would change as the ability to set time changes
[16:25] <mlichvar> for units that enable the service as a dependency, that would be a good thing I guess
[16:25] <cpaelzer> -X would have none of these issues, it would always be "systemctl <cmd> chrony"
[16:26] <cpaelzer> I never used OnFailure + replace - maybe it would even work?
[16:26] <cpaelzer> mlichvar: did you use that before?
[16:26] <mlichvar> no, just saw that in the man page
[16:27] <cpaelzer> mlichvar: I might do some experiments with that, lets roughly outline the design here
[16:27] <cpaelzer> a service like chrony-nosync
[16:27] <cpaelzer> haivng -x added as option
[16:27] <cpaelzer> set to replace the service if it fails
[16:27] <cpaelzer> mlichvar: is that the TL;DR to start a test on?
[16:28] <cpaelzer> just to agree on the scope
[16:28] <mlichvar> yes, I think
[16:28] <cpaelzer> If it works, I'm good - otherwise I'm back requesting my -X :-)
[16:28] <cpaelzer> mlichvar: i'll let you know - ok ?
[16:28] <mlichvar> ok
[16:29] <mlichvar> in any case, I think it would be good to improve the error message in initialization
[16:30] <cpaelzer> suggestions?
[16:32] <mlichvar> I mean, even if we don't have -X, it would be good to say it's missing the capability
[16:32] <cpaelzer> agreed