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://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1589780 Title: chrony.service doesn't start on LXD container To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1589780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs