[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#910753: marked as done (apt: Race condition between apt's systemd timers & cloud-init)

Your message dated Fri, 13 Mar 2020 17:48:23 -0400
with message-id <20200313214823.GA2665@morgul.net>
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 owner@bugs.debian.org
immediately.)


-- 
910753: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910753
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 ---
Reply to: