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