control: reopen 990069
control: found 990069 2.31-13
control: tag 990069 + patch
On 2021-08-01 00:05, Ron wrote:
>
> Hi,
>
> Sadly I can confirm this problem still persists in 2.31-13 too. I found
> it (before I found this report of it) yesterday upgrading a fully up to
> date buster vm to bullseye ...
>
> In my case I noticed it at the first conffile prompt when trying to ssh
> a new connection into the vm failed, which was after the first prompting
> from libc to restart services (and ssh was not included in the list of
> services to restart then).
>
> I can confirm that manually restarting ssh (while the upgrade was still
> in progress) did fix it to enable logins again.
>
> The interesting bit of the upgrade log is included below - I'm not sure
> offhand exactly how the libc restart logic is coded, but at first blush
> I'd note the new openssh-server is unpacked but not set up at the time
> the libc service restart takes place ...
>
> Cheers,
> Ron
>
> Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
> Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> Preparing to unpack .../runit-helper_2.10.3_all.deb ...
> Unpacking runit-helper (2.10.3) ...
> Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
> Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> Preparing to unpack .../libc6_2.31-13_amd64.deb ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
> Setting up libc6:amd64 (2.31-13) ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Services to restart for GNU libc library upgrade:
> cron atd
> Restarting services possibly affected by the upgrade:
> cron: restarting...done.
> atd: restarting...done.
> Services restarted successfully.
> Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
> Unpacking libc-bin (2.31-13) over (2.28-10) ...
> Setting up libc-bin (2.31-13) ...
> ...
> <much later>
> ...
> Setting up openssh-server (1:8.4p1-5) ...
Thanks for this upgrade log, with it I have been able to understand and
reproduce the issue. The libc restart logic looks for installed
packaged, however due to all the breaks and depends between
openssh-server and libc6 in the buster -> bullseye upgrade path, it
could happen that at the moment the libc6 postinst script is ran, the
openssh-server has been degraded from installed to unpacked.
I have tested the following fix, which works well when used in the same
conditions as the above log:
diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
index 8406a543..ee99ac16 100644
--- a/debian/script.in/nsscheck.sh
+++ b/debian/script.in/nsscheck.sh
@@ -1,8 +1,8 @@
echo -n "Checking for services that may need to be restarted..."
# Only get the ones that are installed, of the same architecture
# as libc (or arch all) and configured
- check=$(dpkg-query -W -f='${binary:Package} ${Status} ${Architecture}\n' $check 2> /dev/null | \
- grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
+ check=$(dpkg-query -W -f='${binary:Package} ${db:Status-Want} ${Architecture}\n' $check 2> /dev/null | \
+ grep -E "(install|hold) (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
# some init scripts don't match the package names
check=$(echo $check | \
sed -e's/\bapache2.2-common\b/apache2/g' \
However before uploading such a fix so close to the release, I think it
requires a review by many more pair of eyes.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature