Merge Chrony 3.4-4

Bug #1828992 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
chrony (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

While Chrony 3.5 is almost available as ~pre1 release let us pick up all the fixes that accumulated between 3.4-1 and 3.4-4 for Eoan already.

That also gives 3.5 some time to show if it has known issues.

Related branches

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Changes that IMHO are reasonable to submit to Debian for the next merge to drop them::
- 9d1894c d/postrm: re-establish systemd-timesyncd on removal (LP: #1764357)
- 6b6b390 - d/postrm: respect policy-rc.d when restoring systemd-timesyncd (LP: #1771994)

Replacing ours delta for networkd-dispatcher:
8f52063b d/control: Suggest networkd-dispatcher
=> We had used Recommends, but I think we can also work with a suggests as it is a rare case to even be a problem.
18fde15f Update sources in response to systemd-networkd events (LP: #1718227).
=> Taken from us as-is

We can drop those this time.

Minor typo in SYNC_IN_CONTAINER comment fixed.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Who is up?:
Install-Remove timesyncd - ok
Install chrony - ok
Install-Purge-Install chrony - ok
Install-Remove-Install-Reinstall chrony - ok
Install-Remove-Install - timesyncd ??

Ha that is another weird interaction.
Not a bug in our postrm fix for timesyncd/chrony but related.
I removed our postrm change and it stays as-is.

Per https://wiki.debian.org/MaintainerScripts section "Installing from '''Config-Files''' state".
The postinst will call:
  invoke-rc.d chrony restart
And if you run the same after the install it will correctly make chrony run and timesyncd stop.

But in the postinst the restart is from the section of dh_installinit/11.3.2ubuntu1 which comes before the section of dh_installsystemd/11.3.2ubuntu1.
If we'd turn around the order it would work in above case as well.

OTOH I'm not sure if this is a really big issue - after what I found it might affect even more packages that have sysV AND systemd files.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

After discussion and later tests, this is resolved by getting rid of the sysV script.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.2 KiB)

This bug was fixed in the package chrony - 3.4-4ubuntu1

---------------
chrony (3.4-4ubuntu1) eoan; urgency=medium

  * Merge with Debian unstable (LP: #1828992). Remaining changes:
    - d/chrony.conf: use ubuntu ntp pool and server (LP 1744664 1754358)
    - Set -x as default if unable to set time (e.g. in containers) (LP 1589780)
      Chrony is a single service which acts as both NTP client (i.e. syncing the
      local clock) and NTP server (i.e. providing NTP services to the network),
      and that is both desired and expected in the vast majority of cases.
      But in containers syncing the local clock is usually impossible, but this
      shall not break the providing of NTP services to the network.
      To some extent this makes chrony's default config more similar to 'ntpd',
      which complained in syslog but still provided NTP server service in those
      cases.
      + debian/chrony.service: allow the service to run without CAP_SYS_TIME
      + debian/control: add new dependency libcap2-bin for capsh (usually
        installed anyway, but make them explicit to be sure).
      + debian/chrony.default: new option SYNC_IN_CONTAINER to not fall back
        (Default off) [fixed a minor typo in the comment in this update]
      + debian/chronyd-starter.sh: wrapper to handle special cases in containers
        and if CAP_SYS_TIME is missing. Effectively allows to run NTP server in
        containers on a default installation and avoid failing to sync time (or
        if allowed to sync, avoid multiple containers to fight over it by
        accident).
      + debian/install: make chrony-starter.sh available on install.
      + debian/docs, debian/README.container: provide documentation about the
        handling of this case.
    - d/postrm: re-establish systemd-timesyncd on removal (LP 1764357)
    - d/postrm: respect policy-rc.d when restoring systemd-timesyncd
      (LP 1771994)
  * Added Changes:
    - removed d/init to avoid weird interactions between sysV and systemd
  * Dropped Changes:
    - Notify chrony to update sources in response to systemd-networkd
      events (LP: 1718227)
      + d/links: link dispatcher script to networkd-dispatcher events routable
        and off
      + d/control: set Recommends to networkd-dispatcher
      [Those are in Debian, except that we agreed to have networkd-dispatcher
       to only be a Suggests]

chrony (3.4-4) unstable; urgency=medium

  * debian/patches/*:
    - Add allow-further-syscalls-in-seccomp-filter.patch. Supplementing the
    seccomp filter whitelist with those syscalls is a prerequisite, notably for
    the arm64 architecture.

  [ Leigh Brown ]
  * debian/patches/*:
    - Add allow-recv-send-in-seccomp-filter.patch. Necessary on armel and
    ppc64el. Other architectures might also be affected. (Closes: #924494)

chrony (3.4-3) unstable; urgency=medium

  * debian/.gitlab-ci.yml:
    - Check for missing hardening flags.

  * debian/patches/*:
    - Add allow-_llseek-in-seccomp-filter.patch. Needed on various 32-bit
    plateforms to log the {raw}measurements and statistics information when
    the seccomp filter is enabled. Thanks a lot to Francesco Poli (wintermute)
  ...

Read more...

Changed in chrony (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.