Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Hi, On 2021-08-12 21:51, Andres Salomon wrote: > Hi, > > So this only affects users who do or do not have the ssh metapackage > installed? This bug report is a bit confusing. > It used to affects all users who do or do not have the ssh metapackage installed, however following the fix that went into 2.31-13, all users are now affected. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
On Thu, 12 Aug 2021 21:51:09 -0400 Andres Salomon wrote: > So this only affects users who do or do not have the ssh metapackage > installed? I'm pretty sure it effects both. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Hi, So this only affects users who do or do not have the ssh metapackage installed? This bug report is a bit confusing. Thanks, Andres
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
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) ...
> > > > ...
> > > >
> > > > ...
> > > > 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
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
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) ...
> > > ...
> > >
> > > ...
> > > 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.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
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) ...
> > ...
> >
> > ...
> > 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
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
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) ...
> ...
>
> ...
> 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
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
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) ... ... ... Setting up openssh-server (1:8.4p1-5) ...
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Package: libc6 Version: 2.31-13 Followup-For: Bug #990069 X-Debbugs-Cc: olafvds...@gmail.com Dear Maintainer, The original issue of not being able to open a new SSH connection during the upgrade still seems to be present. Greetings, Olaf -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6 depends on: ii libcrypt1 1:4.4.18-4 ii libgcc-s1 10.2.1-6 Versions of packages libc6 recommends: ii libidn2-0 2.3.0-5 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.77 pn glibc-doc ii libc-l10n 2.31-13 ii locales2.31-13 -- debconf information: glibc/disable-screensaver: glibc/kernel-not-supported: * libraries/restart-without-asking: true glibc/upgrade: true glibc/kernel-too-old: glibc/restart-services: glibc/restart-failed:
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Hi all, On 04-07-2021 00:42, Colin Watson wrote: > Sorry for my delay - it took me a while to spot the problem. libc6's > postinst does arrange to restart services where needed, but in this case > it doesn't realize that you have the ssh service installed because you > only have the openssh-server package installed, not the ssh metapackage > (i.e. the package with the same name as the service). > > I've proposed > https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix > this. glibc maintainers, if there's any way to get this into bullseye, > I'm sure it would help avoid some people upgrading remote systems ending > up being unable to fix them if something goes wrong between configuring > libc6 and configuring openssh-server. Also CCing debian-release for > their information, as I know it's pretty late for glibc changes. I think we really want this. I *think* I ran into exactly this issue two days ago when I upgraded my NAS. It's really scary to notice that you can't log into your system and your only connection is the current one running the upgrade. In my case, it was asking questions along the way. I had considered running the upgrade in screen. In the end it look longer than expected and I left my laptop on. If I would have run in screen and disconnected, I would have had no idea what hit me. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Op zo 4 jul. 2021 om 00:42 schreef Colin Watson : > Sorry for my delay - it took me a while to spot the problem. libc6's > postinst does arrange to restart services where needed, but in this case > it doesn't realize that you have the ssh service installed because you > only have the openssh-server package installed, not the ssh metapackage > (i.e. the package with the same name as the service). > > I've proposed > https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix > this. glibc maintainers, if there's any way to get this into bullseye, > I'm sure it would help avoid some people upgrading remote systems ending > up being unable to fix them if something goes wrong between configuring > libc6 and configuring openssh-server. Also CCing debian-release for > their information, as I know it's pretty late for glibc changes. Thanks Colin! I assume openssh-server would then be restarted after the "There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded." question. But ssh is already 'down' when that question is being asked, so wouldn't there still be a time window, with required user interaction, where ssh would be 'down'? -- Olaf
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Control: reassign -1 libc6 2.31-12 Control: affects -1 openssh-server On Sat, Jul 03, 2021 at 11:36:49AM +0200, Olaf van der Spek wrote: > Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek : > > So I think it's not accepting new connections from the start of the > > upgrade run until the end: > > Setting up openssh-sftp-server (1:8.4p1-5) ... > > Setting up console-setup (1.203) ... > > Setting up mime-support (3.66) ... > > Setting up openssh-server (1:8.4p1-5) ... > > Installing new version of config file /etc/init.d/ssh ... > > Installing new version of config file /etc/ssh/moduli ... > > Replacing config file /etc/ssh/sshd_config with new version > > rescue-ssh.target is a disabled or a static unit, not starting it. > > Hi Colin, > > Any thoughts on this? Sorry for my delay - it took me a while to spot the problem. libc6's postinst does arrange to restart services where needed, but in this case it doesn't realize that you have the ssh service installed because you only have the openssh-server package installed, not the ssh metapackage (i.e. the package with the same name as the service). I've proposed https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix this. glibc maintainers, if there's any way to get this into bullseye, I'm sure it would help avoid some people upgrading remote systems ending up being unable to fix them if something goes wrong between configuring libc6 and configuring openssh-server. Also CCing debian-release for their information, as I know it's pretty late for glibc changes. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek : > > So I think it's not accepting new connections from the start of the > upgrade run until the end: > Setting up openssh-sftp-server (1:8.4p1-5) ... > Setting up console-setup (1.203) ... > Setting up mime-support (3.66) ... > Setting up openssh-server (1:8.4p1-5) ... > Installing new version of config file /etc/init.d/ssh ... > Installing new version of config file /etc/ssh/moduli ... > Replacing config file /etc/ssh/sshd_config with new version > rescue-ssh.target is a disabled or a static unit, not starting it. Hi Colin, Any thoughts on this? -- Olaf
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
So I think it's not accepting new connections from the start of the upgrade run until the end: Setting up openssh-sftp-server (1:8.4p1-5) ... Setting up console-setup (1.203) ... Setting up mime-support (3.66) ... Setting up openssh-server (1:8.4p1-5) ... Installing new version of config file /etc/init.d/ssh ... Installing new version of config file /etc/ssh/moduli ... Replacing config file /etc/ssh/sshd_config with new version rescue-ssh.target is a disabled or a static unit, not starting it.
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Op za 19 jun. 2021 om 13:13 schreef Colin Watson : > > On Sat, Jun 19, 2021 at 12:53:48PM +0200, Olaf van der Spek wrote: > > During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be > > accepting new connections. IMO this is less than optimal, and not sure if > > this was always the case. > > Would it be possible to keep accepting connections, or at least to make the > > time window in which SSH is down as short as possible? FYI, this is when it's waiting for a reply to this question: Configuring libc6:amd64 | There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions | | of service for the system, you will normally be prompted on each upgrade for the list of services you wish to restart. You can choose this option to avoid being prompted; instead, all | | necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade. | | | | Restart services during package upgrades without asking? $ ssh localhost kex_exchange_identification: read: Connection reset by peer Connection reset by ::1 port 22 /var/log/auth: Jun 20 10:00:43 alpha sshd[10140]: fatal: recv_rexec_state: buffer error: incomplete message > That's odd, because we already take care to do that. Any chance of some > logs? I think the most useful things would be /var/log/dpkg.log, 2021-05-09 10:03:01 status installed systemd:amd64 241-7~deb10u7 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade base-files:amd64 10.3+deb10u9 10.3+deb10u10 2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u9 2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u9 2021-06-20 09:40:28 status half-installed base-files:amd64 10.3+deb10u9 2021-06-20 09:40:28 status triggers-pending man-db:amd64 2.8.5-2 2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 status installed base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade libgcrypt20:amd64 1.8.4-5 1.8.4-5+deb10u1 2021-06-20 09:40:28 status triggers-pending libc-bin:amd64 2.28-10 2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5 2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5 2021-06-20 09:40:28 status half-installed libgcrypt20:amd64 1.8.4-5 2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 status installed libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade libnettle6:amd64 3.4.1-1 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1 2021-06-20 09:40:28 status half-installed libnettle6:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status installed libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade libhogweed4:amd64 3.4.1-1 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1 2021-06-20 09:40:28 status half-installed libhogweed4:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status installed libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:29 upgrade libgnutls30:amd64 3.6.7-4+deb10u6 3.6.7-4+deb10u7 2021-06-20 09:40:29 status half-configured libgnutls30:amd64 3.6.7-4+deb10u6 2021-06-20 09:40:29 status unpacked libgnutls30:amd64 3.6.7-4+deb10u6 2021-06-20 09:40:29 status half-installed libgnutls30:amd64 3.6.7-4+deb10u6 2021-06-20 09:40:29 status
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
On Sat, Jun 19, 2021 at 12:53:48PM +0200, Olaf van der Spek wrote: > During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be > accepting new connections. IMO this is less than optimal, and not sure if > this was always the case. > Would it be possible to keep accepting connections, or at least to make the > time window in which SSH is down as short as possible? That's odd, because we already take care to do that. Any chance of some logs? I think the most useful things would be /var/log/dpkg.log, /var/log/apt/term.log, and the bits of "journalctl -b -u ssh.service" that show when sshd stopped and started. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Package: openssh-server Version: 1:8.4p1-5 Severity: normal Dear Maintainer, During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be accepting new connections. IMO this is less than optimal, and not sure if this was always the case. Would it be possible to keep accepting connections, or at least to make the time window in which SSH is down as short as possible? Greetings, Olaf -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii libaudit1 1:2.8.4-3 iu libc6 2.31-12 ii libcom-err21.44.5-1+deb10u3 ii libcrypt1 1:4.4.18-4 ii libgssapi-krb5-2 1.17-3+deb10u1 ii libkrb5-3 1.17-3+deb10u1 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux13.1-3 ii libssl1.1 1.1.1d-0+deb10u6 ii libsystemd0241-7~deb10u7 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 iu openssh-client 1:8.4p1-5 iu openssh-sftp-server1:8.4p1-5 ii procps 2:3.3.15-2 iu runit-helper 2.10.3 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 241-7~deb10u7 ii ncurses-term 6.1+20181013-2+deb10u2 ii xauth1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn ssh-askpass pn ufw -- debconf information: openssh-server/permit-root-login: true openssh-server/password-authentication: true
