Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
On Tue, Aug 03, 2021 at 10:08:42PM +0200, Aurelien Jarno wrote:
> On 2021-08-01 00:05, Ron wrote:
> >
> > 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.
Again flying blind to a lot of important details -- but what happens if
libc postinst tries to restart a service that is unpacked but not yet
configured?
I'm guessing that depends a lot on what the service post* do, but how
horrible could that get? Does this really need to be a trigger that
(also?) restarts each of the half-installed services after they are
fully (re)configured again?
I was able to restart ssh manually during the upgrade, but by the time I
figured out that was what was needed, the install was probably far enough
through that it had likely been configured and was fully installed again ...
Cheers,
Ron
Reply to: