Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1021289: apt-listbugs: behaviour under unattended-upgrades is suboptimal; do pinning in `apt update` step?

68 views
Skip to first unread message

Paul Wise

unread,
Oct 4, 2022, 9:30:04 PM10/4/22
to
Package: apt-listbugs
Version: 0.1.36
Severity: normal

The behaviour of apt-listbugs under unattended-upgrades is suboptimal:

 * It causes the apt run to abort before it can start.
    - With minimal steps mode some packages may be upgraded, but once a
      bug is found, no subsequent package upgrade steps can be run.
 * The messages say that pinning is being added but they are not added.

Since unattended-upgrades are not interactive the user can never
interact with apt-listbugs to add pinning and cannot restart the apt
session, which is currently required for the pinning to take effect.

For this reason I suggest that when in non-interactive mode, a hook for
APT::Update::Post-Invoke (run by `apt update`) is added that will
invoke apt-listbugs and add pinning for any packages that need pinning
added and removing any that no longer apply. At this point apt-listbugs
should not do any prompting or errors, since it is not running in the
interactive mode. Then when `apt upgrade` is run the apt-listbugs hook
will see pinning, not abort the upgrade and the upgrade will complete,
minus the packages that could not be upgraded due to bugs.

Please set the Explanation field to say that the package pin was added
automatically, so that sysadmins reading it understand that the pin was
added by apt-listbugs rather than being set by a sysadmin.

-- System Information:
Debian Release: bookworm/sid
 APT prefers testing-debug
 APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii apt 2.5.3
ii ruby 1:3.0+3.1
ii ruby-debian 0.3.10+b7
ii ruby-gettext 3.3.3-2
ii ruby-soap4r 2.0.5-5
ii ruby-unicode 0.4.4.4-1+b4
ii ruby-xmlparser 0.7.3-4+b3

Versions of packages apt-listbugs recommends:
ii ruby-httpclient 2.8.3+git20211122.4658227-1

Versions of packages apt-listbugs suggests:
ii chromium [www-browser] 106.0.5249.91-1
ii dillo [www-browser] 3.0.5-7+b1
ii elinks [www-browser] 0.13.2-1+b3
ii firefox [www-browser] 105.0.1-1
ii firefox-esr [www-browser] 102.3.0esr-1
ii links [www-browser] 2.27-1+b1
ii lynx [www-browser] 2.9.0dev.10-1+b1
ii netsurf-gtk [www-browser] 3.10-1+b3
ii reportbug 11.5.1
ii sensible-utils 0.0.17
ii w3m [www-browser] 0.5.3+git20220429-1+b1
ii xdg-utils 1.1.3-4.1

-- no debconf information

--
bye,
pabs

https://wiki.debian.org/PaulWise
signature.asc

Francesco Poli

unread,
Oct 6, 2022, 6:30:07 PM10/6/22
to
Control: tags -1 + moreinfo


On Wed, 05 Oct 2022 09:18:55 +0800 Paul Wise wrote:

> Package: apt-listbugs
> Version: 0.1.36
> Severity: normal

Hi Paul,
thanks for your bug report.

>
> The behaviour of apt-listbugs under unattended-upgrades is suboptimal:
>
>  * It causes the apt run to abort before it can start.
>     - With minimal steps mode some packages may be upgraded, but once a
>       bug is found, no subsequent package upgrade steps can be run.
>  * The messages say that pinning is being added but they are not added.

This sounds awkward to me, since there's code in apt-listbugs to detect
non-interactive sessions and modify the behavior accordingly.

Specifically, when apt-listbugs sees that its stdout is not a terminal,
it automatically assume the following options: --quiet --force-pin
--force-no
This automatic behavior change should ensure that all buggy packages
(of the upgrade/installation that is about to happen) are pinned,
without any interactive prompt.

I assume unattended-upgrades runs the package manager without connecting
stdout to a terminal...
More investigation is needed in order to figure out why you didn't see
the pinning added.
I assume unattended-upgrades runs the package manager with root
privileges...

>
> Since unattended-upgrades are not interactive the user can never
> interact with apt-listbugs to add pinning and cannot restart the apt
> session, which is currently required for the pinning to take effect.

Did you configure unattended-upgrades to attempt the upgrade twice in a
row (as suggested in the FAQ[^note])?

[^note]: see /usr/share/doc/apt-listbugs/FAQ.md.gz

I admit that I am not familiar with unattended-upgrades, hence I am not
sure how to configure it for the twice-in-a-row upgrade.
I hope it's easy enough.

>
> For this reason I suggest that when in non-interactive mode, a hook for
> APT::Update::Post-Invoke (run by `apt update`) is added that will
> invoke apt-listbugs and add pinning for any packages that need pinning
> added and removing any that no longer apply.

I think this cannot work, unfortunately.

In order to know which packages are going to be upgraded (or newly
installed!), apt-listbugs must receive information from the upgrade (or
install) session of the package manager.

The update of the repository indexes is not enough, since the package
manager does not yet know what the user will request (just install one
or two packages? upgrade all the package that can be upgraded? upgrade
only some packages? nothing at all for the time being, since the
upgrade/install will happen later?).

And apt-listbugs would anyway be unable to distinguish between
non-interactive repository index updates and non-interactive updates
immediately followed by non-interactive upgrades.
I mean: some users desire unattended repository index updates, but want
to do the package upgrade interactively. If apt-listbugs is invoked
during an "update" and sees that stdout is not a terminal, how can it
tell whether this is an unattended "update" or an unattended "update +
upgrade"?

[...]
> Please set the Explanation field to say that the package pin was added
> automatically, so that sysadmins reading it understand that the pin was
> added by apt-listbugs rather than being set by a sysadmin.

This could perhaps be done, but I am not sure I see its usefulness.

A sysadmin who uses some unattended package upgrade mechanism will see
a good number of automatically added pins. Possibly (almost) never a
pin added during an interactive session.
On the other hand, a sysadmin who does not use any unattended package
upgrade mechanism, will only see interactively added pins.



--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

Paul Wise

unread,
Oct 6, 2022, 8:40:03 PM10/6/22
to
Control: retitle -1 apt-listbugs: automatic pinning is not added under unattended-upgrades

Refocusing this bug report on the pinning issue.

On Fri, 2022-10-07 at 00:26 +0200, Francesco Poli wrote:

> Specifically, when apt-listbugs sees that its stdout is not a terminal,
> it automatically assume the following options: --quiet --force-pin
> --force-no
> This automatic behavior change should ensure that all buggy packages
> (of the upgrade/installation that is about to happen) are pinned,
> without any interactive prompt.

I tested this again and it definitely is not happening, see below.

Reading the code, it seems the issue is that the save() function is
only ever called by the view() function when the answer is y/n but
never when the answer is p which is set by --force-pin.

> I assume unattended-upgrades runs the package manager without connecting
> stdout to a terminal...

I think that is correct given the output below.

> More investigation is needed in order to figure out why you didn't see
> the pinning added.

Provided some debugging at the end of this mail.

> I assume unattended-upgrades runs the package manager with root
> privileges...

Correct.

> Did you configure unattended-upgrades to attempt the upgrade twice in a
> row (as suggested in the FAQ[^note])?

I hadn't read the FAQ, thanks for the pointer. In this case the pinning
issue would prevent it from working anyway.

> I admit that I am not familiar with unattended-upgrades, hence I am not
> sure how to configure it for the twice-in-a-row upgrade.
> I hope it's easy enough.

I can only configure unattended-upgrades to run more often, there is no
option to ignore failure of a particular upgrade and retry it.

> I think this cannot work, unfortunately.
>
> In order to know which packages are going to be upgraded (or newly
> installed!), apt-listbugs must receive information from the upgrade (or
> install) session of the package manager.

I see, that makes sense.

Here is the debugging for the pinning issue.

$ apt list --upgradable
Listing... Done
libreadline-dev/testing,unstable 8.2-1 amd64 [upgradable from: 8.2~rc2-2]
libreadline8-dbgsym/testing-debug,unstable-debug 8.2-1 amd64 [upgradable from: 8.2~rc2-2]
libreadline8/testing,unstable 8.2-1 amd64 [upgradable from: 8.2~rc2-2]

$ apt upgrade -s
NOTE: This is only a simulation!
apt needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
libreadline-dev libreadline8 libreadline8-dbgsym
3 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
Inst libreadline8-dbgsym [8.2~rc2-2] (8.2-1 Debian debug:testing-debug, Debian debug:unstable-debug [amd64]) []
Inst libreadline-dev [8.2~rc2-2] (8.2-1 Debian:testing, Debian:unstable [amd64]) []
Inst libreadline8 [8.2~rc2-2] (8.2-1 Debian:testing, Debian:unstable [amd64])
Conf libreadline8-dbgsym (8.2-1 Debian debug:testing-debug, Debian debug:unstable-debug [amd64])
Conf libreadline-dev (8.2-1 Debian:testing, Debian:unstable [amd64])
Conf libreadline8 (8.2-1 Debian:testing, Debian:unstable [amd64])

$ apt-listbugs list libreadline-dev libreadline8 libreadline8-dbgsym
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of libreadline8 (-> ) <Outstanding>
b1 - #1021062 - bash: non existent locale crashes bash
Summary:
libreadline8(1 bug)

$ cat /etc/apt/preferences.d/apt-listbugs
$

$ systemctl start apt-daily-upgrade.service

$ cat /etc/apt/preferences.d/apt-listbugs
$

$ tail -n12 /var/log/unattended-upgrades/unattended-upgrades.log
2022-10-07 07:42:26,918 INFO Starting unattended upgrades script
2022-10-07 07:42:26,919 INFO Allowed origins are: origin=Debian,codename=bookworm,label=Debian, origin=Debian,codename=bookworm,label=Debian-Security, origin=Debian,codename=bookworm-security,label=Debian-Security, origin=Debian
2022-10-07 07:42:26,919 INFO Initial blacklist:
2022-10-07 07:42:26,919 INFO Initial whitelist (not strict):
2022-10-07 07:42:41,539 INFO Packages that will be upgraded: libreadline-dev libreadline8 libreadline8-dbgsym
2022-10-07 07:42:41,540 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2022-10-07 07:42:45,879 ERROR Installing the upgrades failed!
2022-10-07 07:42:45,879 ERROR error message: installArchives() failed
2022-10-07 07:42:45,879 ERROR dpkg returned a error! See /var/log/unattended-upgrades/unattended-upgrades-dpkg.log for details
2022-10-07 07:42:46,439 INFO Package libreadline-dev is kept back because a related package is kept back or due to local apt_preferences(5).
2022-10-07 07:42:46,443 INFO Package libreadline8 is kept back because a related package is kept back or due to local apt_preferences(5).
2022-10-07 07:42:46,452 INFO Package libreadline8-dbgsym is kept back because a related package is kept back or due to local apt_preferences(5).

$ tail -n12 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Log started: 2022-10-07 07:42:41
grave bugs of libreadline8 (8.2~rc2-2 → 8.2-1) <Outstanding>
b1 - #1021062 - bash: non existent locale crashes bash
Summary:
libreadline8(1 bug)
libreadline8 will be pinned. Restart APT session to enable
**********************************************************************
****** Exiting with an error in order to stop the installation. ******
**********************************************************************
E:Sub-process /usr/bin/apt-listbugs apt returned an error code (10), E:Failure running script /usr/bin/apt-listbugs apt
Log ended: 2022-10-07 07:42:45

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
libreadline-dev libreadline8 libreadline8-dbgsym
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/693 kB of archives.
After this operation, 2,048 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of libreadline8 (8.2~rc2-2 -> 8.2-1) <Outstanding>
b1 - #1021062 - bash: non existent locale crashes bash
Summary:
libreadline8(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] d b1
The following 1 bug will be dodged:
b1
Are you sure? [Y/n] y
libreadline8 will be pinned. Restart APT session to enable
Are you sure you want to install/upgrade the above packages? [N/?/...]
**********************************************************************
****** Exiting with an error in order to stop the installation. ******
**********************************************************************
E: Sub-process /usr/bin/apt-listbugs apt returned an error code (10)
E: Failure running script /usr/bin/apt-listbugs apt

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ cat /etc/apt/preferences.d/apt-listbugs

Explanation: Pinned by apt-listbugs at 2022-10-07 07:57:06 +0800
Explanation: #1021062: bash: non existent locale crashes bash
Package: libreadline8
Pin: version 8.2~rc2-2
Pin-Priority: 30000
signature.asc

Francesco Poli

unread,
Oct 12, 2022, 6:40:03 PM10/12/22
to
Control: tags -1 - moreinfo


On Fri, 07 Oct 2022 08:36:36 +0800 Paul Wise wrote:

[...]
> Refocusing this bug report on the pinning issue.
>
> On Fri, 2022-10-07 at 00:26 +0200, Francesco Poli wrote:
>
> > Specifically, when apt-listbugs sees that its stdout is not a terminal,
> > it automatically assume the following options: --quiet --force-pin
> > --force-no
> > This automatic behavior change should ensure that all buggy packages
> > (of the upgrade/installation that is about to happen) are pinned,
> > without any interactive prompt.
>
> I tested this again and it definitely is not happening, see below.
>
> Reading the code, it seems the issue is that the save() function is
> only ever called by the view() function when the answer is y/n but
> never when the answer is p which is set by --force-pin.

Paul, I really have to thank you for reporting this bug and for
investigating it (through tests and by reading the code)!
It turns out that this regression was introduced (shame on me!) when I
decided to defer the update of files to the end of the apt-listbugs
session. The deferment was useful to implement the undo ('u') command.
But, unfortunately, I didn't realize that save() would not be called at
all in the force-pin case... :-(

Now everything seems to work as intended: the pinnings are saved, even
when apt-listbugs is run with no controlling terminal.

[...]
> > More investigation is needed in order to figure out why you didn't see
> > the pinning added.
>
> Provided some debugging at the end of this mail.

Thanks again, the debugging session you provided was also pretty useful
to understand what was going on!

[...]
> > I admit that I am not familiar with unattended-upgrades, hence I am not
> > sure how to configure it for the twice-in-a-row upgrade.
> > I hope it's easy enough.
>
> I can only configure unattended-upgrades to run more often, there is no
> option to ignore failure of a particular upgrade and retry it.
[...]

Support for attempting unattended upgrades twice in a row could perhaps
be added to file '/usr/lib/apt/apt.systemd.daily'.
Please note that this file is shipped in package 'apt'.

One way to implement it is maybe by adding the following code before
line 495:

if [ "$TwiceInARow" = "true" ]; then
unattended-upgrade $XUUPOPT
fi

The surrounding snippet of code would thus become something like:

if command -v unattended-upgrade >/dev/null && check_stamp $UPGRADE_STAMP $UnattendedUpgradeInterval; then
if [ "$TwiceInARow" = "true" ]; then
unattended-upgrade $XUUPOPT
fi
if unattended-upgrade $XUUPOPT; then
update_stamp $UPGRADE_STAMP
debug_echo "unattended-upgrade (success)"
else
debug_echo "unattended-upgrade (error)"
fi
else
debug_echo "unattended-upgrade (not run)"
fi


Near line 402 something like the following could be added:

TwiceInARow="false"
eval $(apt-config shell TwiceInARow APT::Periodic::Twice-in-a-Row)


This is totally untested and based on a quick glance at the file.
There could be better ways.

Please take a look at it and see whether you like it.
Maybe you could enhance this rough idea a bit and propose it to APT
developers...

Paul Wise

unread,
Oct 12, 2022, 9:50:04 PM10/12/22
to
On Thu, 2022-10-13 at 00:29 +0200, Francesco Poli wrote:

> Now everything seems to work as intended: the pinnings are saved, even
> when apt-listbugs is run with no controlling terminal.

Excellent, thanks for fixing!


> Thanks again, the debugging session you provided was also pretty useful
> to understand what was going on!

Great :)


> Support for attempting unattended upgrades twice in a row could perhaps
> be added to file '/usr/lib/apt/apt.systemd.daily'.
> There could be better ways.
>
> Please take a look at it and see whether you like it.
> Maybe you could enhance this rough idea a bit and propose it to APT
> developers...

Hmm. I think I would prefer a protocol for the apt hooks to ask for apt
to restart the current upgrade. Not sure what apt folks think though,
I'll bring it up on their mailing list and CC you.
signature.asc
0 new messages