| Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
Few more thoughts about this.
On Tue, Mar 13, 2018 at 05:40:56PM +0100, Christian Ehrhardt wrote:
> [17:28] <cpaelzer> We have two cases how this can run
> [17:28] <cpaelzer> 1. if this runs on a Host that can set time, it has to
> be in sync with what it serves time to - so it needs to set local time
> [17:28] <cpaelzer> so for #1 it is a requirement
> [17:29] <cpaelzer> 2. if it runs in a container then we know the host is
> already synced to the same source that chrony in the container gets its
> time (so I got told)
If we know the host is synchronizing the system clock, forcing chronyd
to run in a container with no CAP_SYS_TIME (using -x or -X) would not
be recommended. If there is no way to avoid that, it would probably be
better to configure chronyd to synchronize its virtual clock with the
host instead of the remote servers so its adjustments don't disturb
chronyd's measurements. The maxclockerror value should be increased in
any case.
I see how this option could simplify configuration and deployment of
systems. I'm just not sure if we should be encouraging people to use
chronyd in a wrong way.
--
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.