newly installed additional units are not started on upgrade

Bug #1707880 reported by Dimitri John Ledkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
New
Undecided
Unassigned
Zesty
New
Undecided
Unassigned
Artful
New
Undecided
Unassigned
debhelper (Ubuntu)
Fix Released
Undecided
Unassigned
Zesty
New
Undecided
Unassigned
Artful
New
Undecided
Unassigned

Bug Description

Upon upgrading apt from a version that only ships apt-daily.timer to the one that ships apt-daily.timer and apt-daily-upgrade.timer, the latter is not started on zesty and later.

I believe this may be a bug in dh_systemd_start:

# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
 systemctl --system daemon-reload >/dev/null || true
 if [ -n "$2" ]; then
  _dh_action=try-restart
 else
  _dh_action=start
 fi
 deb-systemd-invoke $_dh_action apt-daily-upgrade.timer apt-daily.timer >/dev/null || true
fi
# End automatically added section

This reduces to:
deb-systemd-invoke try-restart apt-daily-upgrade.timer apt-daily.timer >/dev/null || true

which is (after calling/checking policy-rc.d) is:
systemctl try-restart apt-daily-upgrade.timer apt-daily.timer >/dev/null || true

This is correct, for the apt-daily.timer and does nothing for the apt-daily-upgrade.timer. Since apt-daily-upgrade.timer is not active, try-restart does not start it.

Imho, there should be an extra snippet in apt.postinst which does this:

if [ -d /run/systemd/system ]; then
 if dpkg --compare $2 with version that introduces apt-daily-upgrade.timer; then
         deb-systemd-invoke start apt-daily-upgrade.timer >/dev/null || true
 fi
fi

tags: added: rls-aa-incoming
tags: removed: rls-aa-incoming
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Or as per adam. If the deb-systemd-invoke tracks magic state at install time, and knows which units are brand new, it should do start on those, and retry-start on the known updated units.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package debhelper - 10.10.9ubuntu1

---------------
debhelper (10.10.9ubuntu1) bionic; urgency=medium

  * Merge from current Debian unstable. Remaining changes:
    - Generate ddebs from debhelper instead of pkg-create-dbgsym
      + Make debhelper Conflict/Replace pkg-create-dbgsym to force it off.
      + Set DBGSYM_PACKAGE_TYPE to ddeb to get correct debian/files output.
    - dh_installchangelogs: Do not install upstream changelog in compat
      level 7 and higher to avoid pointlessly bloating installed packages.

debhelper (10.10.9) unstable; urgency=medium

  [ Dmitry Shachnev ]
  * qmake.pm: Add missing import of generated_file.
  * meson.pm: Find typo of meson in the name of the cross config
    file.
  * qmake.pm: Push compiler information as ‘early’ flags to qmake, to
    make sure qmake calls the right compiler to get library paths.
  * qmake.pm: Add all possible settings to generated qmake-cross.conf.
    Now output of ‘qmake -query’ with and without using this file is
    identical. This makes cross-building Qt’s own modules possible.

  [ Niels Thykier ]
  * dh_missing: Permit a missing debian/tmp without failing in
    compat 11 when debian/tmp is an implicit source directory.
    Thanks to Christoph Biedl for reporting the bug.
    (Closes: #882083)
  * dh_missing: Improve the wording about "debian/not-installed".

 -- Adam Conrad <email address hidden> Tue, 21 Nov 2017 14:26:40 -0700

Changed in debhelper (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.