On 2024-07-25 11:49:42 +0200, Vincent Lefevre wrote:
> The reload is triggered with just
>
> 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.
And if the timer time has been reached, the apt-daily service is run.
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.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
