Public bug reported: A long time ago, chrony grew an Ubuntu patch to better work inside container [1],[2]. This patch allows running chrony inside a container but, in this scenario, chrony is unable to discipline the clock as most containers don't have the required permissions/privileges to do so.
As such, it allows a specific (niche) scenario for those wanting to serve the time over the network without being able to discipline the local clock. However, to do so, the admin has to first configure chrony to serve the time over the network as it does not do it by default. Now, in [3], chrony is proposed to replace systemd-timesyncd everywhere to gain support for NTS. This is a good idea but I think it'd be best if chrony could also default to being inactive inside containers. This could be achieved by having a `ConditionVirtualization=!container` clause like systemd-timesyncd has. This way, if an admin really wants to run chrony to serve the time over the network, he/she would need to `systemctl edit` the `ConditionVirtualization=` clause away and alter chrony's config to listen over the network. This is slightly more work (for the override) but would only be needed for the specific/niche scenario. The main advantage of adding `ConditionVirtualization=!container` to chrony's unit would be to avoid wasting resources inside container for the general case. Since physical machines can have 100s or 1000s of containers, wasted resources have compounding effects. 1: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1589780 2: https://git.launchpad.net/ubuntu/+source/chrony/tree/debian/README.container 3: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2111342 ** Affects: chrony (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2111535 Title: chrony should not run inside containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2111535/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
