During an upgrade with aptitude 0.8.13-6, I got: Extracting templates from packages: 100% Preconfiguring packages ... (Reading database ... 417244 files and directories currently installed.) Preparing to unpack .../bsdutils_1%3a2.40-8_amd64.deb ... Unpacking bsdutils (1:2.40-8) over (1:2.40-6) ... Setting up bsdutils (1:2.40-8) ... (Reading database ... 417244 files and directories currently installed.) Preparing to unpack .../libperl5.38t64_5.38.2-4_amd64.deb ... Unpacking libperl5.38t64:amd64 (5.38.2-4) over (5.38.2-3.2+b2) ... Preparing to unpack .../perl_5.38.2-4_amd64.deb ... Unpacking perl (5.38.2-4) over (5.38.2-3.2+b2) ... Preparing to unpack .../perl-base_5.38.2-4_amd64.deb ... Unpacking perl-base (5.38.2-4) over (5.38.2-3.2+b2) ... Setting up perl-base (5.38.2-4) ... (Reading database ... 417241 files and directories currently installed.) Preparing to unpack .../0-perl-modules-5.38_5.38.2-4_all.deb ... Unpacking perl-modules-5.38 (5.38.2-4) over (5.38.2-3.2) ... Preparing to unpack .../1-eject_2.40-8_amd64.deb ... Unpacking eject (2.40-8) over (2.40-6) ... Preparing to unpack .../2-bsdextrautils_2.40-8_amd64.deb ... Unpacking bsdextrautils (2.40-8) over (2.40-6) ... Preparing to unpack .../3-util-linux-extra_2.40-8_amd64.deb ... Adding 'diversion of /sbin/ctrlaltdel to /sbin/ctrlaltdel.usr-is-merged by util-linux-extra' Adding 'diversion of /sbin/fsck.cramfs to /sbin/fsck.cramfs.usr-is-merged by util-linux-extra' Adding 'diversion of /sbin/fsck.minix to /sbin/fsck.minix.usr-is-merged by util-linux-extra' Adding 'diversion of /sbin/mkfs.bfs to /sbin/mkfs.bfs.usr-is-merged by util-linux-extra' Adding 'diversion of /sbin/mkfs.cramfs to /sbin/mkfs.cramfs.usr-is-merged by util-linux-extra' Adding 'diversion of /sbin/mkfs.minix to /sbin/mkfs.minix.usr-is-merged by util-linux-extra' Unpacking util-linux-extra (2.40-8) over (2.40-6) ... Preparing to unpack .../4-fdisk_2.40-8_amd64.deb ... Unpacking fdisk (2.40-8) over (2.40-6) ... Preparing to unpack .../5-libsmartcols1_2.40-8_amd64.deb ... Unpacking libsmartcols1:amd64 (2.40-8) over (2.40-6) ... Setting up libsmartcols1:amd64 (2.40-8) ... (Reading database ... 417253 files and directories currently installed.) Preparing to unpack .../libblkid1_2.40-8_amd64.deb ... Unpacking libblkid1:amd64 (2.40-8) over (2.40-6) ... Setting up libblkid1:amd64 (2.40-8) ... (Reading database ... 417253 files and directories currently installed.) Preparing to unpack .../libmount1_2.40-8_amd64.deb ... Unpacking libmount1:amd64 (2.40-8) over (2.40-6) ... Setting up libmount1:amd64 (2.40-8) ... (Reading database ... 417253 files and directories currently installed.) Preparing to unpack .../mount_2.40-8_amd64.deb ... Unpacking mount (2.40-8) over (2.40-6) ... Preparing to unpack .../libuuid1_2.40-8_amd64.deb ... Unpacking libuuid1:amd64 (2.40-8) over (2.40-6) ... Setting up libuuid1:amd64 (2.40-8) ... (Reading database ... 417253 files and directories currently installed.) Preparing to unpack .../util-linux_2.40-8_amd64.deb ... Unpacking util-linux (2.40-8) over (2.40-6) ... Setting up util-linux (2.40-8) ... fstrim.service is a disabled or a static unit not running, not starting it. dpkg: error: dpkg frontend lock was locked by another process with pid 58569 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. ====== How can you help? (doc: https://wiki.debian.org/how-can-i-help ) ====== ----- Show old opportunities as well as new ones: how-can-i-help --old ----- E: Sub-process /usr/bin/dpkg returned an error code (2) Setting up bsdextrautils (2.40-8) ... dpkg: dependency problems prevent configuration of fdisk: fdisk depends on libfdisk1 (= 2.40-8); however: Version of libfdisk1:amd64 on system is 2.40-6. dpkg: error processing package fdisk (--configure): dependency problems - leaving unconfigured Setting up eject (2.40-8) ... Setting up perl-modules-5.38 (5.38.2-4) ... Setting up mount (2.40-8) ... Setting up libperl5.38t64:amd64 (5.38.2-4) ... Setting up util-linux-extra (2.40-8) ... Setting up perl (5.38.2-4) ... Processing triggers for libc-bin (2.37-19) ... Processing triggers for man-db (2.12.1-1) ... Processing triggers for mailcap (3.70+nmu1) ... Errors were encountered while processing: fdisk There seem to be 2 issues: one with the dpkg lock (which may be bug 1069183 in aptitude) and one with fdisk. It is not clear whether they are related. At least, bug 1069183 shouldn't be the cause of a bad ordering between package unpacking and setup, which would rather be due to a dependency problem, as indicated by the dpkg error message.
* Vincent Lefevre <vincent@vinc17.net> [240428 22:33]: ... Possible. I see no evidence of that in the log. C
Here's the /var/log/apt/history.log part that corresponds to this upgrade: Start-Date: 2024-04-28 22:05:30 Upgrade: libsmartcols1:amd64 (2.40-6, 2.40-8), libvpx8:amd64 (1.13.1-2, 1.13.1-2+b1), libltdl7:amd64 (2.4.7-7, 2.4.7-7+b1), libpaper1:amd64 (1.1.29, 1.1.29+b1), libnftnl11:amd64 (1.2.6-2, 1.2.6-2+b1), asymptote:amd64 (2.87+ds-1+b1, 2.89+ds-1), va-driver-all:amd64 (2.20.0-2, 2.20.0-2+b1), libdevel-size-perl:amd64 (0.83-2+b3, 0.84-1), libxrender1:amd64 (1:0.9.10-1.1, 1:0.9.10-1.1+b1), util-linux-locales:amd64 (2.40-6, 2.40-8), libglvnd0:amd64 (1.7.0-1, 1.7.0-1+b1), perl:amd64 (5.38.2-3.2+b2, 5.38.2-4), libx11-xcb1:amd64 (2:1.8.7-1, 2:1.8.7-1+b1), libxshmfence1:amd64 (1.3-1, 1.3-1+b1), libxml2-dev:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), libmatch-simple-xs-perl:amd64 (0.001-4, 0.002-1), libunwind8:amd64 (1.6.2-3, 1.6.2-3+b1), libldap-common:amd64 (2.5.16+dfsg-2, 2.5.17+dfsg-1), libxml2-utils:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), libxkbfile1:amd64 (1:1.1.0-1, 1:1.1.0-1+b1), libfile-mimeinfo-perl:amd64 (0.34-1, 0.35-1), xsltproc:amd64 (1.1.35-1, 1.1.35-1+b1), libpciaccess0:amd64 (0.17-3, 0.17-3+b1), libxcursor1:amd64 (1:1.2.1-1, 1:1.2.1-1+b1), codespell:amd64 (2.2.6-1, 2.2.6-2), libmime-tools-perl:amd64 (5.514-1, 5.515-1), libglx0:amd64 (1.7.0-1, 1.7.0-1+b1), vim-common:amd64 (2:9.1.0199-1, 2:9.1.0377-1), libsigsegv2:amd64 (2.14-1, 2.14-1+b1), libmaa4:amd64 (1.4.7-1, 1.4.7-1+b1), libva-x11-2:amd64 (2.20.0-2, 2.20.0-2+b1), libgsm1:amd64 (1.0.22-1, 1.0.22-1+b1), libmount1:amd64 (2.40-6, 2.40-8), libxau6:amd64 (1:1.0.9-1, 1:1.0.9-1+b1), libxcomposite1:amd64 (1:0.4.5-1, 1:0.4.5-1+b1), libxs-parse-keyword-perl:amd64 (0.39-1+b2, 0.41-1), libatasmart4:amd64 (0.19-5, 0.19-5+b1), libdevel-callchecker-perl:amd64 (0.008-2+b2, 0.009-1), libxdamage1:amd64 (1:1.1.6-1, 1:1.1.6-1+b1), libsepol2:amd64 (3.5-2, 3.5-2+b1), libmnl0:amd64 (1.0.5-2, 1.0.5-2+b1), libxml2:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), util-linux:amd64 (2.40-6, 2.40-8), libvdpau1:amd64 (1.5-2, 1.5-2+b1), util-linux-extra:amd64 (2.40-6, 2.40-8), libldap-2.5-0:amd64 (2.5.16+dfsg-2, 2.5.17+dfsg-1), libgav1-1:amd64 (0.19.0-2, 0.19.0-2+b1), libgpg-error0:amd64 (1.47-3, 1.47-3+b1), libxss1:amd64 (1:1.2.3-1, 1:1.2.3-1+b1), libxcvt0:amd64 (0.1.2-1, 0.1.2-1+b1), libassuan-dev:amd64 (2.5.6-1, 2.5.6-1+b1), libcompress-raw-lzma-perl:amd64 (2.211-1, 2.212-1), libcdr-0.1-1:amd64 (0.1.7-1, 0.1.7-1+b1), fdisk:amd64 (2.40-6, 2.40-8), libgles2:amd64 (1.7.0-1, 1.7.0-1+b1), libyaml-0-2:amd64 (0.2.5-1, 0.2.5-1+b1), libxxf86dga1:amd64 (2:1.1.5-1, 2:1.1.5-1+b1), libxfont2:amd64 (1:2.0.6-1, 1:2.0.6-1+b1), libfdisk1:amd64 (2.40-6, 2.40-8), libassuan0:amd64 (2.5.6-1, 2.5.6-1+b1), libsoxr0:amd64 (0.1.3-4, 0.1.3-4+b1), eject:amd64 (2.40-6, 2.40-8), libltdl-dev:amd64 (2.4.7-7, 2.4.7-7+b1), libxkbcommon0:amd64 (1.6.0-1, 1.6.0-1+b1), libxtst6:amd64 (2:1.2.3-1.1, 2:1.2.3-1.1+b1), vdpau-driver-all:amd64 (1.5-2, 1.5-2+b1), libnet-dns-sec-perl:amd64 (1.23-1+b2, 1.24-1), libuuid1:amd64 (2.40-6, 2.40-8), libvisual-0.4-0:amd64 (0.4.2-2, 0.4.2-2+b1), libjpeg62-turbo:amd64 (1:2.1.5-2+b2, 1:2.1.5-3), libgcrypt20:amd64 (1.10.3-2, 1.10.3-2+b1), python3-numpy:amd64 (1:1.26.4+ds-6, 1:1.26.4+ds-8), perl-doc:amd64 (5.38.2-3.2, 5.38.2-4), vim-tiny:amd64 (2:9.1.0199-1, 2:9.1.0377-1), xcvt:amd64 (0.1.2-1, 0.1.2-1+b1), libice6:amd64 (2:1.0.10-1, 2:1.0.10-1+b1), liburing2:amd64 (2.5-1, 2.5-1+b1), libid3tag0:amd64 (0.15.1b-14, 0.15.1b-14+b1), asymptote-doc:amd64 (2.87+ds-1, 2.89+ds-1), libopengl0:amd64 (1.7.0-1, 1.7.0-1+b1), libxslt1.1:amd64 (1.1.35-1, 1.1.35-1+b1), libglu1-mesa:amd64 (9.0.2-1.1, 9.0.2-1.1+b1), librevenge-0.0-0:amd64 (0.0.5-3, 0.0.5-3+b1), libogg0:amd64 (1.3.5-3, 1.3.5-3+b1), libxinerama1:amd64 (2:1.1.4-3, 2:1.1.4-3+b1), mount:amd64 (2.40-6, 2.40-8), perl-base:amd64 (5.38.2-3.2+b2, 5.38.2-4), libpaper-utils:amd64 (1.1.29, 1.1.29+b1), libjaylink0:amd64 (0.3.1-1, 0.3.1-1+b1), ed:amd64 (1.20.1-1.1, 1.20.2-2), libblkid1:amd64 (2.40-6, 2.40-8), libxvmc1:amd64 (2:1.0.12-2, 2:1.0.12-2+b1), libva-drm2:amd64 (2.20.0-2, 2.20.0-2+b1), perl-modules-5.38:amd64 (5.38.2-3.2, 5.38.2-4), libgl1:amd64 (1.7.0-1, 1.7.0-1+b1), libegl1:amd64 (1.7.0-1, 1.7.0-1+b1), libx11-6:amd64 (2:1.8.7-1, 2:1.8.7-1+b1), libperl5.38t64:amd64 (5.38.2-3.2+b2, 5.38.2-4), libxkbcommon-x11-0:amd64 (1.6.0-1, 1.6.0-1+b1), liblz1:amd64 (1.14-1, 1.15~pre1-1), libemf1:amd64 (1.0.13-7, 1.0.13-7+b1), libwpg-0.3-3:amd64 (0.3.4-3, 0.3.4-3+b1), libgpg-error-dev:amd64 (1.47-3, 1.47-3+b1), libedit2:amd64 (3.1-20230828-1, 3.1-20230828-1+b1), bsdutils:amd64 (1:2.40-6, 1:2.40-8), libsm6:amd64 (2:1.2.3-1, 2:1.2.3-1+b1), libva2:amd64 (2.20.0-2, 2.20.0-2+b1), bsdextrautils:amd64 (2.40-6, 2.40-8), libxfixes3:amd64 (1:6.0.0-2, 1:6.0.0-2+b1), libxdmcp6:amd64 (1:1.1.2-3, 1:1.1.2-3+b1), libxv1:amd64 (2:1.0.11-1.1, 2:1.0.11-1.1+b1), libutempter0:amd64 (1.2.1-3, 1.2.1-3+b1), libspectre1:amd64 (0.2.12-1, 0.2.12-1+b1), libevdev2:amd64 (1.13.1+dfsg-1, 1.13.1+dfsg-1+b1) Error: Sub-process /usr/bin/dpkg returned an error code (2) End-Date: 2024-04-28 22:05:34 One can see "libfdisk1:amd64 (2.40-6, 2.40-8)", which was not done.
Hi! I don't think dpkg is at fault here, I assume something else is either getting activated in the middle of the transaction while the package manager frontend driving dpkg has released the lock (which it should not), or the package manager frontend driving dpkg is performing the locking dance incorrectly. Right, it seems to me, like when dpkg fails due to the already held lock, then the frontend is not recomputing the transaction and keeps as if nothing had gone incorrectly, until it then notices later on. In any case, given that dpkg is not being very helpful in diagnosing this, I'll implement support to print the process name in addition to the pid, as this has also hit me, and it's never clear what was the actual culprit. So that's why I'm leaving this assigned to dpkg, but with a lower severity. If you'd like to file this elsewhere, then please clone and reassign that. Thanks, Guillem
Isn't dpkg able to install/uninstall a set of packages in an atomic way (where dpkg itself would set a lock at the beginning and release the lock once every install/uninstall has been done, so that a lock failure would not be possible in the middle of the installation)? Alternatively, if this is too complicated, it could abort and let the user fix things (which is currently needed anyway). It seems that the "dpkg frontend lock is locked by another process" error almost always occurs with the same packages: either util-linux or apt. See bugs * 933335 Unpacking util-linux (2.34-0.1) over (2.33.1-0.1) ... dpkg: error: dpkg frontend lock is locked by another process Setting up apt (2.6.1) ... dpkg: error: dpkg frontend lock was locked by another process with pid 4191235 * 940961 Unpacking apt (1.8.4) over (1.8.3) ... dpkg: error: dpkg frontend lock is locked by another process * 1069183 Setting up util-linux-extra (2.38.1-5+deb12u1) ... dpkg: error: dpkg frontend lock was locked by another process with pid 1064194 * 1070027 (this bug) Setting up util-linux (2.40-8) ... fstrim.service is a disabled or a static unit not running, not starting it. dpkg: error: dpkg frontend lock was locked by another process with pid 58569 I'm wondering whether there could be a reason... But there's also bug 1062190: Unpacking locales (2.36-9+deb12u4) over (2.36-9+deb12u3) ... dpkg: error: dpkg frontend lock was locked by another process with pid 567573
Hi! Sure, but that's not how apt-based frontends do it, as they call dpkg multiples times over an upgrade process. I'd first focus on finding and fixing the part that is interfering with the locking. But in any case that would be something for apt-based frontends to handle. and they are executed each as their own dpkg run. I've been running now for a while with a modified dpkg with the improved reporting, which I'll be merging for the next release. And managed to get the failure with the process name. I was running this this session with aptitude. I got this: ,--- […] (Reading database ... 343670 files and directories currently installed.) Preparing to unpack .../util-linux_2.40.1-7_amd64.deb ... Unpacking util-linux (2.40.1-7) over (2.40.1-4) ... Setting up util-linux (2.40.1-7) ... fstrim.timer is a disabled or a static unit not running, not starting it. fstrim.service is a disabled or a static unit not running, not starting it. dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 1310180 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 1310180 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 1310180 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. E: Sub-process /usr/bin/dpkg returned an error code (2) E: Sub-process dpkg --set-selections returned an error code (2) E: Couldn't revert dpkg selection for approved remove/purge after an error was encountered! E: Sub-process dpkg --set-selections returned an error code (2) E: Couldn't restore dpkg selection states which were present before this interaction! dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 1310180 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. Press Return to continue, 'q' followed by Return to quit. `--- Checking around I see that the systemd apt-daily.timer triggered at just the same time, so that seems like the most likely culprit. So I guess it makes sense for this report to be cloned and reassigned or so. Regards, Guillem
Hi, Why do they do that while it is possible to give dpkg several packages to install (upgrade)? And why doesn't the frontend log the different calls in/var/log/apt/history.log? I'm talking specifically about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070027#19 Start-Date: 2024-04-28 22:05:30 [...] Error: Sub-process /usr/bin/dpkg returned an error code (2) End-Date: 2024-04-28 22:05:34 and in the journalctl output at this time: Apr 28 22:05:33 disset systemd[1]: Reloading requested from client PID 58469 ('systemctl') (unit session-796.scope)... Apr 28 22:05:33 disset systemd[1]: Reloading... Apr 28 22:05:34 disset systemd[1]: Reloading finished in 102 ms. Apr 28 22:05:34 disset systemd[1]: Starting apt-daily.service - Daily apt download activities... Apr 28 22:05:34 disset systemd[1]: fstrim.timer: Deactivated successfully. Apr 28 22:05:34 disset systemd[1]: Stopped fstrim.timer - Discard unused filesystem blocks once a week. Apr 28 22:05:34 disset systemd[1]: Stopping fstrim.timer - Discard unused filesystem blocks once a week... Apr 28 22:05:34 disset systemd[1]: Started fstrim.timer - Discard unused filesystem blocks once a week. Apr 28 22:05:34 disset systemd[1]: Reloading requested from client PID 58516 ('systemctl') (unit session-796.scope)... Apr 28 22:05:34 disset systemd[1]: Reloading... Apr 28 22:05:34 disset systemd[1]: Reloading finished in 110 ms. Apr 28 22:05:34 disset systemd[1]: apt-daily.service: Deactivated successfully. Apr 28 22:05:34 disset systemd[1]: Finished apt-daily.service - Daily apt download activities. But I've never requested a reloading at this time! So there's something broken related to systemd.
Hi! Bug #1070027 in package dpkg reported by you has been fixed in the dpkg/dpkg.git Git repository. You can see the changelog below, and you can check the diff of the fix at: https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=99bba12f0 --- libdpkg: Try to print the executable name of the lock contending process Just printing the PID is not very useful to try to track down the contending process as its presence might be momentary and might no longer be present when the user tries to look for that specific PID. Try to get the executable name to give a better hint to what might be going wrong. Closes: #1070027
We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1070027@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 17 Jul 2024 01:10:42 +0200
Source: dpkg
Architecture: source
Version: 1.22.7
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Closes: 872381 882511 1069846 1070011 1070027 1070144 1071078 1071124 1072332 1075769
Changes:
dpkg (1.22.7) unstable; urgency=medium
.
[ Guillem Jover ]
* dpkg-buildpackage: Remove fallback handling for missing required targets.
* dpkg-buildpackage: Fix the debian/rules executable check to respect -R.
* dpkg-realpath: Rewrite in C.
* Revert "test: Pass -T+1 to xz to workaround spurious warning with xz
5.6.0".
* dpkg-genbuildinfo: Parse Provides as virtual packages.
* dpkg: Do not run hooks or loggers with --dry-run or while unprivileged.
Closes: #1071124
* dpkg-shlibdeps: Add support for new --package option.
* dpkg-buildpackage: Make newline injection during signing GnuPG specific.
See https://dev.gnupg.org/T7106.
* dpkg-realpath: Do not allow an empty pathname argument.
* dpkg-buildpackage: Add support for building from a specified .dsc or dir.
* dpkg-buildpackage: Reference the .dsc in .buildinfo if building from one.
Closes: #882511
* Perl modules:
- Dpkg::BuildDriver: Refactor build driver out of dpkg-buildpackage.
- Dpkg::Vendor::Ubuntu: Use -fcf-protection=none instead of
-fno-cf-protection. Thanks to Matthias Klose <doko@ubuntu.com>.
- Dpkg::Vendor::Debian: On native builds map *_FOR_BUILD flags to * flags.
Closes: #1072332
- Dpkg::OpenPGP::ErrorCodes: Update error codes from SOP draft version 10.
See https://ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-10.html.
- Dpkg::Vendor::Debian: Set -Wno-error on qa=-bug-implicit-func.
Closes: #1075769
- Dpkg::Shlibs::Cppfilt: Normalize demangled symbols with llvm or C++11
format.
- Dpkg::Archive::Ar: New module.
- Dpkg::Vendor::Debian: Guarantee UTF-8 locale codeset on sanitize-env.
- Dpkg::Substvars: Add support for required substvars assigned with !=.
- Dpkg::Source::Package: Document method additions with an object.
- Dpkg::Source::Package::V3::Bzr: Remove unused variables.
- Dpkg::Source::Package: Add a new get_basedirname() method.
* Make fragments:
- Protect files against double inclusion.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Use filter instead of findstring.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Use explicit test of $(origin) instead of ?=.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Search once for parallel= in DEB_BUILD_OPTIONS.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Generate the _FOR_BUILD variant of each variable automatically.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Reduce the number of subprocesses.
Thanks to Nicolas Boulenguez <nicolas@debian.org>. Closes: #872381
- Stop hard-coding dpkg_datadir.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
* Documentation:
- doc: Add missing full stop to end of sentence.
- man: Document DEB_BUILD_ARCH and DEB_HOST_ARCH usage in commands.
Prompted by Thorsten Glaser <tg@mirbsd.de>.
- man: Add new libdpkg(7) manual page.
- man: Document DPKG_COLORS and DPKG_NLS for all perl scripts honoring
them.
- man: Document missing Packages front-end fields in dpkg-query(1).
- man: Document weak checksum algorithms.
- man: Update verify format example to also include M.
- doc: Fix grammar for fallback.
- doc: Fix casing after admonition.
* Code internals:
- libdpkg: Factor out filesystem database file loading into new function.
Based on a patch by Simon Richter <sjr@debian.org>.
- libcompat: Include missing <string.h> in strnlen module.
Reported by Simon Richter <sjr@debian.org>.
- dpkg-buildpackage: Refactor build target hook execution.
- libdpkg: Handle readlink() failures in file_readlink().
- libdpkg: Change varbuf_get_str() to return "" instead of initializing it.
- libdpkg: Rename varbuf_get_str() to varbuf_str().
- Use varbuf_str() instead of direct access.
- libdpkg: Always NUL terminate varbufs.
- libdpkg: Remove varbuf_end_str() function.
- libdpkg: Add support for DPKG_NLS environment variable.
- libdpkg: Add new varbuf prefix and suffix handling functions.
- libdpkg: Add new file_getcwd() function.
- dpkg: Use a variable for each conffile pathname type.
- src: Fix timestamp parse error reporting. See #1069846.
- src: Check whether SOURCE_DATE_EPOCH is set before parsing it.
Based on a patch by Rainer Weikusat <rweikusat@cyberadapt.com>.
Closes: #1069846
- libdpkg: Add missing header includes.
- libdpkg: Make file_slurp_fd() NUL-terminate the varbuf.
- libdpkg: Refactor lax problem reporting into parse_lax_problem()
function.
- libdpkg: Turn the warning on Provides version relation into a lax error.
See #930317.
- libdpkg: Make varbuf_detach() always return a string.
- libdpkg: Factor fsys_list_parse_buffer() out of
ensure_packagefiles_available().
- dpkg-shlibdeps: Refactor executable CLI parsing.
- dpkg: Refactor conffile disappearing check into a new function.
- Merge conffile obsolete and remove-on-upgrade into a single flags member.
- lib, src: Include missing <stdbool.h>.
Reported by Simon Richter <sjr@debian.org>.
- dpkg-ar: New internal ar implementation script.
- start-stop-daemon: Fix typos in code comments.
- libcompat: Fix vasprintf() to error out if vsnprintf() returns >=
INT_MAX.
- libdpkg: Do not accept len >= INT_MAX in fd_read() and fd_write().
- dpkg-realpath: Switch direct varbuf accesses to varbuf_str().
- Revert "dpkg-realpath: Switch direct varbuf accesses to varbuf_str()".
See https://bugs.debian.org/1076061.
- dpkg-realpath: Guarantee varbufs have been allocated.
- Check for < 0 instead of == -1 from syscall return values.
- Check for >= 0 instead of != -1 for syscall return values.
- dpkg: Check for < 0 instead of == -1 for conffderef() return values.
- libdpkg: Check for limit >= 0 instead of != -1 in buffer_copy().
- libdpkg: Check for updateslength < 0 instead of == -1 in ulist_select().
- dselect: Use enum values instead of literal integers.
- libdpkg: Add new execname module.
- libdpkg: Try to print the executable name of the lock contending process.
Closes: #1070027
- perl: Use new Dpkg::Source::Package->get_basedirname() method.
* Build system:
- Re-enable the sanitizer for functional tests in CI.
- Add missing space before backslash line continuation character.
- Unconditionally include <stddef.h>.
- Do not check for memcpy(). Reported by Simon Richter <sjr@debian.org>.
- Do not check for functions used unconditionally.
- Partially revert the sanitizer for some functional tests in CI.
- Print the release version at the end of configure.
- Add support to track release VCS commit id.
- Pass abs_srcdir and abs_builddir to the TAP driver.
- Rework subst handling for built or installed artifacts.
- Workaround Tap::Harness verbose misbehavior on parallel mode.
See https://github.com/Perl-Toolchain-Gang/Test-Harness/issues/105.
- Fix test verbose and parallel option propagation.
- Add missing files and sort POTFILES.in.
- Check whether HAVE_* macros for headers are defined.
- Include a .dist-vcs-url file in the distributed tarball.
- Do not include VCS specific files in the distributed tarball.
* Packaging:
- Suppress start-stop-daemon compat symlink if /sbin is missing.
Thanks to Johannes Schauer Marin Rodrigues <josch@debian.org>.
Closes: #1071078
* Test suite:
- Do not fail the functional test suite due to memory leaks.
- Pass --check-level=exhaustive to cppcheck.
- Unset DEB_BUILD_MAINT_OPTIONS in build flags tests.
- Simplify buildflags.mk test of _MAINT_APPEND when TEST_ is empty.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Use loops instead of repetitions in mk fragment tests.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Replace double quotes with single quote in shell recipes.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Test exported variables in addition to Make variables.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Test variable override.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Test DEB_CXXFLAGS_MAINT_SET.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Add missing test for CPP build tool.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Test override of a build tool.
Thanks to Nicolas Boulenguez <nicolas@debian.org>.
- Refactor real and virtual package setup.
Based on a patch by Johannes Schauer Marin Rodrigues <josch@debian.org>.
- Set CC to gcc in make fragments functional tests.
- Parametrize all Makefile fragment functional tests.
- Clarify the Makefile fragment variable being tested via comments.
- Add new DPKG_CHECK_DIFF macro to abstract file comparisons.
- Only execute Dpkg::Shlibs checks on ELF platforms.
- Unify all ar invocations into create, extract and list.
- Refactor ar handling into m4 macros.
- Switch ar m4 macros to use internal dpkg-ar implementation.
* Localization:
- Update Dutch man pages translations.
Thanks to Frans Spiesschaert <Frans.Spiesschaert@yucom.be>.
Closes: #1070144
- Update Swedish translations.
Thanks to Peter Krefting <peter@softwolves.pp.se>. Closes: #1070011
.
[ Helge Kreutzmann ]
* Localization:
- Update German man pages translation.
- Update German scripts translation.
.
[ Sven Joachim ]
* Localization:
- Update German programs translation.
Checksums-Sha1:
ae4f19e30fdf59adaf213e9f07f966fe0ad8f5a6 3140 dpkg_1.22.7.dsc
f4a97502a8095872f7bbb1a1ff060f1af8fac897 5690388 dpkg_1.22.7.tar.xz
a45111dbbed432b265a4af1da91cde7286868296 8031 dpkg_1.22.7_amd64.buildinfo
Checksums-Sha256:
352013c812f04aa95a30e75d993a38b260ee23753e9f1419c7137f9b1680df76 3140 dpkg_1.22.7.dsc
2ca0c8e13be4bc14621245bb89438adaba61d3e517a9da17fa15a7e90c98826c 5690388 dpkg_1.22.7.tar.xz
7b678a1a94ee2518876ee11d6f2b972406b1fb17baacb90123b74c6500d9f1b0 8031 dpkg_1.22.7_amd64.buildinfo
Files:
d71caafc10e235e948f8fa230ef2d7d8 3140 admin required dpkg_1.22.7.dsc
c1d9b07694259a3b4fad9ad5bc02c64a 5690388 admin required dpkg_1.22.7.tar.xz
e6343cd0475297d89c39f1472eef8997 8031 admin required dpkg_1.22.7_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
wsG7BAEBCgBvBYJmlwHlCRC5cr8+pK5Xo0cUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmfI0eNBnxOnenFXzqv4TfXkKSoxalHXRSdkbMF9m1M2
GBYhBE8+dPQ2BQwQ9WlldLlyvz6krlejAABp+A//bWGCzBVur9pI1Zy99MO2yq4c
zhYMgRzSAFTS1GeQY4nXwQxS0NAZCLs2jSdcrAv0VTtqZsQ/g8kItAwiRac5jQwk
s0Eh87O121HeZON4VYEJ/YtI161zt9qlpN2lJMjeoBKNkfe7d+y/FjMS+6c/S2y/
hju3ch6MC81NpYJB3CXMmJY6JKZfuuGpQv/kPMHvj42z3HwwvkB8Bwd66BEbs7T4
5jNgffMaO/W1PJwUWj4Jz3C0ZLAnJExomf+sk7i/RUruA8hDGwmlVD5zM61z2nP/
nZ4tUJ0tKMP4vDU6sy8FDrHQodDvr+rA0Noh4YQZGw5Vbt0IiltAg0KFcM6CDq6A
0nX+UNFRkymtJKiTQKGihrkcNDaSyY1QBLzNuU2bg+mNLgPalbNdvGylGotuT7rP
qkIIjQfT7ESUMlRDnahXwSTcR+RPiiPXbOoect72rknXnl0b/opid0umuSuGR8NQ
aeyUOqVGo5c8xRWcqTnL6JF1CbjQfe+c6JuC4xTIEV70E1AsEduIlC0zd9mnyajp
v53bq4SRbFLGMpbCoQPSTnT3Cj3oHqI+QUzTslFfr3C9QA2RytbxjHgjvjlilbN0
UgAGvdTP3T3SOkzRZ2s5p+lIE7TUwYZDZPpmT5Sf+2xFLgTWIVSl2O1/aWh0eEtb
U92XmV+QeB928mFJOSI=
=roKf
-----END PGP SIGNATURE-----
Control: reopen -1
Control: severity -1 important
Unpacking dpkg (1.22.9) over (1.22.7) ...
Setting up dpkg (1.22.9) ...
dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 326336
But this is rather useless information. Perhaps it should also
write the full "ps -ef" output (something like that) to a file,
though this may be too late.
According to the journalctl output:
Jul 25 10:30:36 qaa systemd[1]: Reload requested from client PID 326242 ('systemctl') (unit session-2.scope)...
Jul 25 10:30:36 qaa systemd[1]: Reloading...
Jul 25 10:30:37 qaa systemd[1]: Reloading finished in 153 ms.
Jul 25 10:30:37 qaa systemd[1]: Starting apt-daily.service - Daily apt download activities...
Jul 25 10:30:37 qaa systemd[1]: apt-daily.service: Deactivated successfully.
Jul 25 10:30:37 qaa systemd[1]: Finished apt-daily.service - Daily apt download activities.
but again, I did *not* do a systemctl. So either systemd is completely
broken, or perhaps the systemctl was done by dpkg itself. Note that in
this latter case (I would not be surprised, because when this happens,
this is *always* during an upgrade), even if aptitude had some fix of
frontend locking, there would still be a conflict between aptitude and
dpkg, both leading to a request a lock.
The PPID (with the process name) of 326242 would have been useful,
but systemd does not give it.
Control: retitle -1 dpkg failure at "Setting up" due to dpkg frontend lock by apt-get via apt-daily.service
In /var/lib/dpkg/info/dpkg.postinst I can see
systemctl --system daemon-reload >/dev/null || true
I'm wondering whether this is the cause.
This line is there due to
# Due to #932360 in debhelper we need to explicitly tell systemd to reload.
dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb
so aptitude and even apt aren't even involved in this bug:
Jul 25 11:47:56 qaa systemd[1]: Reload requested from client PID 333083 ('systemctl') (unit session-2.scope)...
Jul 25 11:47:56 qaa systemd[1]: Reloading...
Jul 25 11:47:56 qaa systemd[1]: Reloading finished in 139 ms.
To try to reproduce the issue, I've copied
/usr/lib/systemd/system/apt-daily.service
/usr/lib/systemd/system/apt-daily.timer
into /etc/systemd/system and edited them.
For /etc/systemd/system/apt-daily.service, I've changed the ExecStart
script pathname and edited the copy of the apt.systemd.daily script to
set VERBOSE=1 and ducplicate the following lines
# check if we can lock the cache and if the cache is clean
if command -v apt-get >/dev/null && ! eval apt-get check $XAPTOPT $XSTDERR ; then
debug_echo "error encountered in cron job with \"apt-get check\"."
exit 0
fi
6 times (as "apt-get check" attempts to lock the cache, thus
giving more chance of failure).
For /etc/systemd/system/apt-daily.timer, I've changed the following
lines to get
OnCalendar=*-*-* *:*:00
RandomizedDelaySec=1m
thus reaching the timer time more often.
Now, whether I use
aptitude reinstall dpkg dpkg-dev
or
apt install --reinstall dpkg dpkg-dev
or
dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb \
/var/cache/apt/archives/dpkg-dev_1.22.9_all.deb
I can get a failure in the apt.systemd.daily script:
Jul 25 12:59:17 qaa systemd[1]: Starting apt-daily.service - Daily apt download activities...
Jul 25 12:59:17 qaa apt.systemd.daily[370789]: error encountered in cron job with "apt-get check".
Jul 25 12:59:17 qaa systemd[1]: apt-daily.service: Deactivated successfully.
Jul 25 12:59:17 qaa systemd[1]: Finished apt-daily.service - Daily apt download activities.
With VERBOSE=2, I could get more details about this failure:
Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt download activities...
Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in cron job with "apt-get check".
Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated successfully.
Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt download activities.
Here, the failure occurs in the apt.systemd.daily, because the
process used for the upgrade got the lock first. But it could
be the other way round, as this could be seen with aptitude.
Hi! [ Please see the entire bug report for more details, otherwise I'm sure Vincent can fill in any missing pieces. ] I added this mostly as a debugging aid, even though I had already kind of tracked the surrounding area for this, I guess I was expecting a clone and reassign or a new bug report filed on apt, but probably I should have done that myself, or not closed the report for the improved debugging output (just adding a reference). Printing more stuff could certainly be helpful, but would be annoying. I'd expect something like this bug not being common, so I'm not sure (at least right now) it's worth it to implement further output, or relying on ps or pstree or similar (which would seem rather meh). A reload is the common operation expected when installing any systemd service file, so if that would cause a dpkg lock issue, then that would be a general problem. This is specific to the interaction of the apt-daily.service and how it ends up locking things. So, as mentioned above, and as we saw earlier in the bug report, it looks like the lock handling in the apt-daily.service is not working, and is interfering with the current run. This needs to be fixed there somehow. Reassigning. Thanks, Guillem
[...] OK. So, in short, apt keeps the lock for too long. The lock should be released by apt for triggers since a lock may be needed by some process run by a trigger.
Control: reassign -1 aptitude Control: retitle -1 aptitude: frontend lock support No that's nonsense. The frontend lock is exactly supposed to be held while running dpkg (which runs the lock). This is working as designed. Now the original bug report is quite clearly about aptitude not implementing frontend lock support, as in it still uses the old API to release all locks to run dpkg and hence the service will steal the frontend lock from it. That's expected and working as designed; a frontend that does not implement frontend locking is vulnerable to the same race as before.
WRONG! You can see above an error *without* using aptitude. Even though there may be a bug in aptitude, there is also a bug related to apt.
If you believe there is another bug then you are free to open another one with a summary, but I am not going to read a wild goose chase thread in this bug about another bug you discover while trying to figure out what's going on with your aptitude. The behavior you show here in this final email with your log is entirely correct: apt-daily.service fails to run because you are holding the lock in an apt execution. This is a feature, not a bug. On upgrades, we do not restart or reload or otherwise interact with either apt-daily service, and the services are ordered so they do not run at the same time either; so you won't see races between the services or races from the service being restarted and lose to a parent apt process. But either way, the service is designed to fail this way. There's a reason it runs twice a day despite only needing to run once a day, precisely to give it a chance to catch up if it missed a run due to a lock. Now you could make it wait for the frontend lock, but whether this is advisable is another story, it certainly will make your original bug report worse: apt is guaranteed to steal aptitude's lock if it starts while aptitude is running, so it seems worthwhile to fix this bug.
You're wrong about that. An upgrade / package installation occasionally executes the apt-daily service, i.e. precisely at the worst time for that! This is precisely why the issue with aptitude is so frequent. I've submitted a new bug about this.
The issue with apt-daily.service, which is sometimes forced to run during package upgrade (yielding a conflict with dpkg lock) is bug 1078166.