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
