Your message dated Fri, 13 Mar 2020 17:48:23 -0400 with message-id <[email protected]> and subject line Re: Bug#910753: apt: Race condition between apt's systemd timers & cloud-init has caused the Debian Bug report #910753, regarding apt: Race condition between apt's systemd timers & cloud-init to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 910753: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910753 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: apt Version: 1.7.0 Severity: normal Hello, When a cloud VM is booted with systemd, the timers for apt's periodic actions are launched in parallel with cloud-init. cloud-init does some initial setup, but it also allows end users to customize the system by e.g., installing packages with apt. Depending on timing, apt-daily can go first and lock the db. If the update takes a while, then the db will still be locked when cloud-init tries to apply the user's customizations. Since this can happen on the first boot, there's no clean way for an end-user to ensure that their packages will install. There's a useful ubuntu-focused discussion of this at [1]. Would you be open to adding cloud-init.target to the After list on apt-daily.timer? If I've understood the issue correctly, this should be sufficient. If units can use Before to delay timer triggers, this could be done on the cloud-init side. But I've been unable to confirm what systemd does with that config. Thanks, Ross [1] - https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (40, 'unstable'), (30, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2017.7 ii gpgv 2.2.10-2 ii libapt-pkg5.0 1.7.0 ii libc6 2.27-6 ii libgcc1 1:8.2.0-7 ii libgnutls30 3.5.19-1 ii libseccomp2 2.3.3-3 ii libstdc++6 8.2.0-7 Versions of packages apt recommends: ii ca-certificates 20170717 Versions of packages apt suggests: pn apt-doc <none> ii aptitude 0.8.11-3 ii dpkg-dev 1.19.0.5 ii gnupg 2.2.10-2 ii gnupg2 2.2.10-2 ii powermgmt-base 1.33 ii synaptic 0.84.3 -- no debconf information
--- End Message ---
--- Begin Message ---On Wed, Oct 10, 2018 at 10:14:14AM -0700, Ross Vandegrift wrote: > When a cloud VM is booted with systemd, the timers for apt's periodic actions > are launched in parallel with cloud-init. cloud-init does some initial > setup, but it also allows end users to customize the system by e.g., > installing packages with apt. > > Depending on timing, apt-daily can go first and lock the db. If the update > takes a while, then the db will still be locked when cloud-init tries to > apply the user's customizations. Since this can happen on the first boot, > there's no clean way for an end-user to ensure that their packages will > install. There's a useful ubuntu-focused discussion of this at [1]. If I'm reading the dependency chain correctly, this is no longer an issue, at least in sid: $ systemd-analyze critical-chain apt-daily.timer The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apt-daily.timer @14.252s └─time-sync.target @14.252s └─chrony.service @14.072s +179ms └─basic.target @14.071s └─sockets.target @14.071s └─uuidd.socket @14.071s └─sysinit.target @14.071s └─cloud-init.service @12.157s +1.913s └─networking.service @9.387s +2.769s └─network-pre.target @9.385s └─cloud-init-local.service @2.666s +6.718s └─systemd-remount-fs.service @2.580s +85ms └─systemd-journald.socket @2.521s └─system.slice @2.518s └─-.slice @2.518s Systemd timers get an implicit "After=sysinit.target", and cloud-init.service explicitly declares "Before=sysinit.target". This seems to be the case in buster as well. I'll mark this as done, but please don't hesitate to reopen it if I'm missing something. noah
--- End Message ---
