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