On 2021-08-04 10:43, Aurelien Jarno wrote: > Hi, > > On 2021-08-04 14:34, Ron wrote: > > 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? > > Well this bug report complains that SSH is unavailable during an upgrade > until the package is fully configured again. For making it available > again as soon as possible, it has to be restarted after the new glibc > has been installed, even if it has only been unpacked at this stage. > > That said you are fully right that it might not work for some other > services. > > > 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 ... > > Given I have been able to reproduce the issue, I have tested the above > patch, and I can confirm that openssh can be restarted when it has only > been unpacked.
Actually, it was exactly what was happening with glibc 2.31-12 for systems where the ssh meta-package was installed. I am afraid that the change actually made things worse for those systems, although it was only working by chance. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net