Re: Impact of multiple NTP implementations in containers on host chronyd

On Fri, 2026-01-16 at 13:04 +0000, Valera Requena, Juan wrote:
>=20
> Hi everyone,
> I have a setup where the host=C2=A0runs chronyd=C2=A0natively to discipli=
ne the system clock. However, we have several applications running in conta=
iners, and for various legacy reasons, some of these containers include the=
ir own NTP implementations (likentpd, sntp, or even other chronyd=C2=A0inst=
ances).
> My main concerns are:
> =C2=A0=C2=A0=C2=A01.=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Will these containerized NTP clients =
interfere with the host's chronyd=C2=A0ability to maintain a stable clock?
> =C2=A0=C2=A0=C2=A02.=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Since they share the same kernel, is =
there a risk of "clock fighting" if a container has enough privileges to ca=
lladjtimex=C2=A0or settimeofday?
> =C2=A0=C2=A0=C2=A03.=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0What is the recommended way to handle=
 this? Should we strictly disable time-setting capabilities in all containe=
rs?
> Any insights or best practices would be greatly appreciated.

On Linux, setting the system clock is protected by CAP_SYS_TIME, see
capabilities(7). So just don't give your containers this capability.
podman/docker drop it by default.

Jan
--=20
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]