Your message dated Tue, 27 Nov 2018 09:57:58 +0100
with message-id <68d6a356-bb0c-d879-4de3-db7a632bc...@debian.org>
and subject line Re: reassign to systemd #912087 | openssh-server: Slow startup
after the upgrade to 7.9p1
has caused the Debian Bug report #912087,
regarding openssh-server: Slow startup after the upgrade to 7.9p1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
912087: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openssh-server
Version: 1:7.9p1-1
Severity: normal
Dear Maintainer,
After yesterdays upgrade to 7.9p1 in testing, openssh-server delays my system's
boot by quite some time.
In fact, it is always the first and slowest to start process in systemd-analyze
blame, with times varying from < 20 seconds most of the time
19.044s ssh.service
2.083s ifupdown-wait-online.service
to this insane 100+ second delay I found out yesterday
1min 24.779s ssh.service
1.120s ifupdown-wait-online.service
Even those 20 seconds are a lot, because due to its delay, my boot time (as
mentioned by systemd-analyze) increased from 5-7 seconds to 20+. The os is on
an ssd drive obviously.
If it helps, I have ipv6 disabled system-wide with this kernel parameter:
ipv6.disable=1.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages openssh-server depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.69
ii dpkg 1.19.2
ii libaudit1 1:2.8.4-2
ii libc6 2.27-6
ii libcom-err2 1.44.4-2
ii libgssapi-krb5-2 1.16.1-1
ii libkrb5-3 1.16.1-1
ii libpam-modules 1.1.8-3.8
ii libpam-runtime 1.1.8-3.8
ii libpam0g 1.1.8-3.8
ii libselinux1 2.8-1+b1
ii libssl1.1 1.1.1-1
ii libsystemd0 239-10
ii libwrap0 7.6.q-27
ii lsb-base 9.20170808
ii openssh-client 1:7.9p1-1
ii openssh-sftp-server 1:7.9p1-1
ii procps 2:3.3.15-2
ii ucf 3.0038
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages openssh-server recommends:
ii libpam-systemd 239-10
ii ncurses-term 6.1+20181013-1
ii xauth 1:1.0.10-1
Versions of packages openssh-server suggests:
pn molly-guard <none>
pn monkeysphere <none>
pn rssh <none>
pn ssh-askpass <none>
pn ufw <none>
-- debconf information:
openssh-server/password-authentication: true
openssh-server/permit-root-login: true
--- End Message ---
--- Begin Message ---
Control: tags -1 wontfix
On Tue, 27 Nov 2018 00:05:22 +0100 Sebastian Andrzej Siewior
<sebast...@breakpoint.cc> wrote:
> control: reassign -1 systemd 239-13
>
> I hereby reassign the bug to systemd.
> The problem is that OpenSSL is now using getrandom() for entropy which
> is not (yet) ready and therefore OpenSSH needs longer for startup by
> simply waiting for entropy.
>
> Theodore Y. Ts'o suggested adding hw-rng to KVM/virt setups [0].
> Everything else should work just "fine".
>
> Either way there is nothing OpenSSL wise that can be done. A similar
> issue [1] has been reported once GnuTLS which to getrandom().
>
> Systemd wise there is
> https://github.com/systemd/systemd/issues/4271
> https://github.com/systemd/systemd/pull/10621
> where people want systemd to systemd to credit entropy. I'm not much a
> fan of that but that is a different story.
>
Sigh, and there is nothing that systemd can do to fix this, so I don't
see a point re-assigning this to systemd (again).
Even if this PR is merged, upstream made it very clear that this will be
explicitly opt-in, so users will still be affected by default.
They might just as well install haveged or configure virtio-rng in such
a case.
Oh well, I case this means we just have to close this issue as wontfix then.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
