Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #85248 > unrolled thread

Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service)

Started bySalvatore Bonaccorso <carnil@debian.org>
First post2025-01-22 10:00 +0100
Last post2025-01-26 18:10 +0100
Articles 6 — 2 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service) Salvatore Bonaccorso <carnil@debian.org> - 2025-01-22 10:00 +0100
    Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service) Francesco Poli <invernomuto@paranoici.org> - 2025-01-23 00:10 +0100
      Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service) Francesco Poli <invernomuto@paranoici.org> - 2025-01-23 00:20 +0100
        Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service) Francesco Poli <invernomuto@paranoici.org> - 2025-01-24 00:20 +0100
    Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service) Salvatore Bonaccorso <carnil@debian.org> - 2025-01-26 14:10 +0100
      Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service) Francesco Poli <invernomuto@paranoici.org> - 2025-01-26 18:10 +0100

#85248 — Bug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service)

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-01-22 10:00 +0100
SubjectBug#1093734: nfs-kernel-server: fails to complete setup during upgrade (stuck while restarting nfs-kernel-server.service)
Message-ID<K7EKC-aRqO-7@gated-at.bofh.it>
Control: tags -1 + unreproducible moreinfo

On Wed, Jan 22, 2025 at 12:29:12AM +0100, Francesco Poli (wintermute) wrote:
> Package: nfs-kernel-server
> Version: 1:2.8.2-1+b1
> Severity: grave
> Justification: causes non-serious data loss
> X-Debbugs-Cc: invernomuto@paranoici.org
> 
> 
> Dear maintainers,
> I encountered a big issue, while upgrading package 'nfs-kernel-server'
> on the box where the NFS server runs (the clients run on the compute
> nodes of an HPC cluster).
> 
> The upgrade:
> 
>   [UPGRADE] nfs-kernel-server:amd64 1:2.8.2-1 -> 1:2.8.2-1+b1
> 
> got stuck at
> 
>   [...]
>   Setting up nfs-kernel-server (1:2.8.2-1+b1) ...
> 
> 
> 
> It looks like it was stuck at the restart of the systemd service:
> 
> # systemctl status nfs-kernel-server.service
> ● nfs-server.service - NFS server and services
>      Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; prese>
>     Drop-In: /run/systemd/generator/nfs-server.service.d
>              └─order-with-mounts.conf
>      Active: activating (start-pre) since Tue 2025-01-21 12:40:52 CET; 10min ago
>         Job: 97667
>  Invocation: ced460d410fe4059b9e8781b35340d70
>        Docs: man:rpc.nfsd(8)
>              man:exportfs(8)
>   Cntrl PID: 249039 (exportfs)
>       Tasks: 3 (limit: 154102)
>      Memory: 680K (peak: 2.5M)
>         CPU: 10ms
>      CGroup: /system.slice/nfs-server.service
>              ├─239857 /usr/sbin/nfsdctl threads 0
>              ├─239918 /usr/sbin/exportfs -au
>              └─249039 /usr/sbin/exportfs -r
> 
> There was a 'nfsdctl' process in uninterruptible sleep (D):
> 
> $  ps -eldaf | grep nf[s]
> 4 D root      239857       1  0  80   0 -   847 -      12:07 ?        00:00:00 /usr/sbin/nfsdctl threads 0
> 5 S root      247511       1  0  80   0 -  1375 -      12:35 ?        00:00:00 /usr/sbin/nfsdcld
> 
> After about 30 min, since trying to kill PID 239857 obviously had no effect,
> and I could not find any other strategy to restart nfs-kernel-server.service,
> I had to reboot the box, thus causing many problems to all the NFS clients.
> 
> After reboot, I could issue:
> 
>   # aptitude --purge-unused safe-upgrade
> 
> which finally completed the upgrade (fixing the nfs-kernel-server package,
> which was left in a partially configured state).
> 
> 
> I have never seen anything like this before, and I have upgraded
> nfs-kernel-server and related packages on Debian machines for quite
> a long time.
> Anyway, this should *not* happen during a system upgrade with
> aptitude or apt!
> 
> I don't know whether bug [#992661] is related or not.
> 
> [#992661]: <https://bugs.debian.org/992661>
> 
> By looking at /var/log/kern.log , I see that a kernel BUG was traced
> at the time when the 'nfsdctl' process got stuck in D state.
> See the attached kern.log snippet.
> 
> Please investigate and fix the issue as soon as possible.
> I really hope we can prevent this from happening again!
> 
> Thanks for your time and dedication.

So I'm not able to reproduce this on a current Debian unstable system
mimicking the upgrade. *But* it is possible we have some races
somehwere as recently discussed at our regular kernel team meeting.

We need first to find a way to trigger the issue in any case.

Regards,
Salvatore

[toc] | [next] | [standalone]

#85258

FromFrancesco Poli <invernomuto@paranoici.org>
Date2025-01-23 00:10 +0100
Message-ID<K7S1b-b1H5-3@gated-at.bofh.it>
In reply to#85248

[Multipart message — attachments visible in raw view] — view raw

On Wed, 22 Jan 2025 09:56:26 +0100 Salvatore Bonaccorso wrote:

[...]
> So I'm not able to reproduce this on a current Debian unstable system
> mimicking the upgrade. *But* it is possible we have some races
> somehwere as recently discussed at our regular kernel team meeting.
> 
> We need first to find a way to trigger the issue in any case.
[...]

Hello Salvatore,
thanks for following up.

If it can help in reproducing the issue, the host (where the NFS server
runs) was a Debian testing (trixie) system up-to-date as of last Friday
(Fri, 17 Jan 2025). This was the starting point, so to speak.
Maybe you can regenerate it from snapshot.debian.org ...

Then, the upgrade that failed to complete cleanly was:

  Will install 72 packages, and remove 0 packages.
  1428 kB of disk space will be used
  ========================================
  [INSTALL, DEPENDENCIES] libldap2:amd64 2.6.9+dfsg-1
  [UPGRADE] apt:amd64 2.9.21 -> 2.9.23
  [UPGRADE] apt-utils:amd64 2.9.21 -> 2.9.23
  [UPGRADE] bsdextrautils:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] bsdutils:amd64 1:2.40.2-13 -> 1:2.40.4-1
  [UPGRADE] curl:amd64 8.11.1-1 -> 8.11.1-1+b1
  [UPGRADE] dconf-gsettings-backend:amd64 0.40.0-4+b3 -> 0.40.0-5
  [UPGRADE] dconf-service:amd64 0.40.0-4+b3 -> 0.40.0-5
  [UPGRADE] dirmngr:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] exim4-base:amd64 4.98-3 -> 4.98-3+b1
  [UPGRADE] exim4-daemon-light:amd64 4.98-3 -> 4.98-3+b1
  [UPGRADE] fdisk:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] gnupg-utils:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] golang-1.23:amd64 1.23.4-2 -> 1.23.5-1
  [UPGRADE] golang-1.23-doc:amd64 1.23.4-2 -> 1.23.5-1
  [UPGRADE] golang-1.23-go:amd64 1.23.4-2 -> 1.23.5-1
  [UPGRADE] golang-1.23-src:amd64 1.23.4-2 -> 1.23.5-1
  [UPGRADE] gpg:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] gpg-agent:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] gpg-wks-client:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] gpgconf:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] gpgsm:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] gpgv:amd64 2.2.46-1 -> 2.2.46-1+b1
  [UPGRADE] gzip:amd64 1.12-1.2 -> 1.13-1
  [UPGRADE] ipxe:amd64 1.21.1+git20220113.fbbdc3926+dfsg-1 -> 1.21.1+git20220113.fbbdc3926+dfsg-2
  [UPGRADE] isc-dhcp-common:amd64 4.4.3-P1-5 -> 4.4.3-P1-5+b1
  [UPGRADE] isc-dhcp-server:amd64 4.4.3-P1-5 -> 4.4.3-P1-5+b1
  [UPGRADE] libapt-pkg6.0t64:amd64 2.9.21 -> 2.9.23
  [UPGRADE] libaudit1:amd64 1:4.0.2-2 -> 1:4.0.2-2+b1
  [UPGRADE] libblkid1:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] libcrypt-dev:amd64 1:4.4.36-5 -> 1:4.4.38-1
  [UPGRADE] libcrypt1:amd64 1:4.4.36-5 -> 1:4.4.38-1
  [UPGRADE] libcurl3t64-gnutls:amd64 8.11.1-1 -> 8.11.1-1+b1
  [UPGRADE] libcurl4t64:amd64 8.11.1-1 -> 8.11.1-1+b1
  [UPGRADE] libdconf1:amd64 0.40.0-4+b3 -> 0.40.0-5
  [UPGRADE] libedit2:amd64 3.1-20240808-1 -> 3.1-20250104-1
  [UPGRADE] libfdisk1:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] libglib2.0-0t64:amd64 2.82.4-1 -> 2.82.4-2
  [UPGRADE] libgtk-3-0t64:amd64 3.24.43-4 -> 3.24.43-5
  [UPGRADE] libgtk-3-common:amd64 3.24.43-4 -> 3.24.43-5
  [UPGRADE] libharfbuzz0b:amd64 10.1.0-2 -> 10.2.0-1
  [UPGRADE] libldap-common:amd64 2.5.19+dfsg-1 -> 2.6.9+dfsg-1
  [UPGRADE] libmount1:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] libnfsidmap1:amd64 1:2.8.2-1 -> 1:2.8.2-1+b1
  [UPGRADE] libpq5:amd64 17.2-1+b1 -> 17.2-1+b2
  [UPGRADE] libpython3.12-minimal:amd64 3.12.8-3 -> 3.12.8-5
  [UPGRADE] libpython3.12-stdlib:amd64 3.12.8-3 -> 3.12.8-5
  [UPGRADE] libpython3.12t64:amd64 3.12.8-3 -> 3.12.8-5
  [UPGRADE] libsasl2-2:amd64 2.1.28+dfsg1-8 -> 2.1.28+dfsg1-8+b1
  [UPGRADE] libsasl2-modules:amd64 2.1.28+dfsg1-8 -> 2.1.28+dfsg1-8+b1
  [UPGRADE] libsasl2-modules-db:amd64 2.1.28+dfsg1-8 -> 2.1.28+dfsg1-8+b1
  [UPGRADE] libsmartcols1:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] libuuid1:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] login:amd64 1:4.16.0-2+really2.40.2-13 -> 1:4.16.0-2+really2.40.4-1
  [UPGRADE] mdadm:amd64 4.3+20241202-1.1 -> 4.4-1
  [UPGRADE] mount:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] nfs-common:amd64 1:2.8.2-1 -> 1:2.8.2-1+b1
  [UPGRADE] nfs-kernel-server:amd64 1:2.8.2-1 -> 1:2.8.2-1+b1
  [UPGRADE] pci.ids:amd64 0.0~2024.11.25-1 -> 0.0~2025.01.13-1
  [UPGRADE] python3-attr:amd64 24.2.0-1 -> 24.3.0-1
  [UPGRADE] python3-fs:amd64 2.4.16-5.1 -> 2.4.16-6
  [UPGRADE] python3-jinja2:amd64 3.1.3-1.1 -> 3.1.3-2
  [UPGRADE] python3-more-itertools:amd64 10.5.0-1 -> 10.6.0-1
  [UPGRADE] python3.12:amd64 3.12.8-3 -> 3.12.8-5
  [UPGRADE] python3.12-minimal:amd64 3.12.8-3 -> 3.12.8-5
  [UPGRADE] python3.12-tk:amd64 3.12.8-3 -> 3.12.8-5
  [UPGRADE] quota:amd64 4.09-1 -> 4.09-1+b1
  [UPGRADE] tzdata:amd64 2024b-4 -> 2024b-6
  [UPGRADE] tzdata-legacy:amd64 2024b-4 -> 2024b-6
  [UPGRADE] ucf:amd64 3.0046 -> 3.0048
  [UPGRADE] util-linux:amd64 2.40.2-13 -> 2.40.4-1
  [UPGRADE] util-linux-locales:amd64 2.40.2-13 -> 2.40.4-1
  ========================================


Please let me know, in case you need any further information that
I can easily gather.
Otherwise, please remove the 'moreinfo' tag, unless it means that the
bug report is waiting for data from other people (but not from me).

Thanks for your time.




-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#85259

FromFrancesco Poli <invernomuto@paranoici.org>
Date2025-01-23 00:20 +0100
Message-ID<K7SaR-b1KW-1@gated-at.bofh.it>
In reply to#85258

[Multipart message — attachments visible in raw view] — view raw

On Thu, 23 Jan 2025 00:02:37 +0100 Francesco Poli wrote:

[...]
> Hello Salvatore,
> thanks for following up.
[...]

By the way, I am also experiencing a huge performance hit on the I/O
through the NFS shares.

Please let me explain. On the host where the NFS server runs (let's
call it "$server"), there is the following '/etc/exports' file:

  $ grep '^[^#]' /etc/exports 
  /home/ 172.16.0.0/22(rw,sync,no_subtree_check,no_root_squash)
  /opt/  172.16.0.0/22(ro,sync,no_subtree_check,no_root_squash)

Please note that 172.16.0.0/22 is the InfiniBand (local) network.

The '/etc/nfs.conf' file has already been summarized (by reportbug)
in the original bug report.

On the hosts where the NFS clients run (let's call them "$client"),
the home NFS share is mounted on /home with the following options
(in the '/etc/fstab' file):

nfs       nofail,nfsvers=3,rdma,port=20049,exec,dev,suid,rw,bg,rsize=32768,wsize=32768,intr

and the same (but with 'ro' in stead of 'rw') for /opt


Well, as of Fri, 17 Jan 2025 (before the upgrade that failed to
complete), I could take a 326 MB binary file and copy it to another
file within the same directory under /home with:

  $ dd if=test.dat of=new.dat status=progress
  $ rm new.dat

On $server (where /home is a local filesystem, on 6 mechanical hard
disks in software RAID6) the result was:

  326091584 bytes (326 MB, 311 MiB) copied, 1.08429 s, 301 MB/s

On each of the $client boxes (where /home is a mounted NFS share through
the InfiniBand network, protocol RDMA, as I have previously said), the
results were:

  326091584 bytes (326 MB, 311 MiB) copied, 2.54522 s, 128 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.64063 s, 123 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.46292 s, 132 MB/s
  [...]

That was not like reading and writing locally, but maybe we can accept
a 2.3 or 2.4 factor for the copying time...

Now, as of Tue, 21 Jan 2025, after the upgrade that failed to complete
on $server, a reboot of $server , the completing of the upgrade
(and an upgrade/reboot of some of the $client boxes, it seems to
make no or very little difference), the results on the $client boxes
are:

  326091584 bytes (326 MB, 311 MiB) copied, 203.068 s, 1.6 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 195.6 s, 1.7 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 139.393 s, 2.3 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 207.157 s, 1.6 MB/s
  [...]
  
The factor for the copying time is now in the range 128÷207
(a slowdown of 52÷84 , compared to before the upgrade)...


I am not sure whether this performance hit is caused by the same
bug that prevented the nfs-kernel-server service from starting,
or by another issue.

Do you need me to file a separate bug report for the performance
hit?

Thanks for any help you may provide!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#85267

FromFrancesco Poli <invernomuto@paranoici.org>
Date2025-01-24 00:20 +0100
Message-ID<K8eEp-bmpA-5@gated-at.bofh.it>
In reply to#85259

[Multipart message — attachments visible in raw view] — view raw

On Thu, 23 Jan 2025 00:12:51 +0100 Francesco Poli wrote:

[...]
> By the way, I am also experiencing a huge performance hit on the I/O
> through the NFS shares.
[...]

I am more and more puzzled.

Now, after some (irrelevant?) package upgrades:

  Will install 12 packages, and remove 0 packages.
  54.3 kB of disk space will be used
  ========================================
  [UPGRADE] fonts-lyx:amd64 2.4.2.1-1 -> 2.4.3-1
  [UPGRADE] gnustep-base-common:amd64 1.30.0-8 -> 1.30.0-9
  [UPGRADE] gnustep-base-runtime:amd64 1.30.0-8 -> 1.30.0-9
  [UPGRADE] libgnustep-base1.30:amd64 1.30.0-8 -> 1.30.0-9
  [UPGRADE] libpango-1.0-0:amd64 1.56.0-3 -> 1.56.1-1
  [UPGRADE] libpangocairo-1.0-0:amd64 1.56.0-3 -> 1.56.1-1
  [UPGRADE] libpangoft2-1.0-0:amd64 1.56.0-3 -> 1.56.1-1
  [UPGRADE] libvulkan1:amd64 1.3.296.0-1 -> 1.4.304.0-1
  [UPGRADE] publicsuffix:amd64 20241206.1516-0.1 -> 20250108.1153-0.1
  [UPGRADE] python3-fonttools:amd64 4.55.3-1 -> 4.55.3-2
  [UPGRADE] python3-urllib3:amd64 2.2.3-4 -> 2.3.0-1
  [UPGRADE] shared-mime-info:amd64 2.4-5+b1 -> 2.4-5+b2
  ========================================

the performance hit seems to have gone away.

On $server :

  326091584 bytes (326 MB, 311 MiB) copied, 1.0812 s, 302 MB/s

On each of the $client boxes (some upgraded and rebooted, some not yet):

  326091584 bytes (326 MB, 311 MiB) copied, 2.64994 s, 123 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.49485 s, 131 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.7485 s, 119 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.40638 s, 136 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.58302 s, 126 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.75766 s, 118 MB/s
  326091584 bytes (326 MB, 311 MiB) copied, 2.76305 s, 118 MB/s
  [...]

Was I seeing ghosts? Am I seeing ghosts?
I really cannot understand...

Let's assume that the performance is back to "expected" values.
I will not file any separate bug report about the NFS performance, for
the time being.

Sorry for the "noise" about performance, let's focus back on the
nfs-kernel-server upgrade that failed to complete.

Please let me know whether there's any progress.
Bye and thanks for your kind assistance!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#85287

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-01-26 14:10 +0100
Message-ID<K9ayJ-c1t0-1@gated-at.bofh.it>
In reply to#85248
Hi Francesco,

On Wed, Jan 22, 2025 at 09:56:26AM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + unreproducible moreinfo
> 
> On Wed, Jan 22, 2025 at 12:29:12AM +0100, Francesco Poli (wintermute) wrote:
> > Package: nfs-kernel-server
> > Version: 1:2.8.2-1+b1
> > Severity: grave
> > Justification: causes non-serious data loss
> > X-Debbugs-Cc: invernomuto@paranoici.org
> > 
> > 
> > Dear maintainers,
> > I encountered a big issue, while upgrading package 'nfs-kernel-server'
> > on the box where the NFS server runs (the clients run on the compute
> > nodes of an HPC cluster).
> > 
> > The upgrade:
> > 
> >   [UPGRADE] nfs-kernel-server:amd64 1:2.8.2-1 -> 1:2.8.2-1+b1
> > 
> > got stuck at
> > 
> >   [...]
> >   Setting up nfs-kernel-server (1:2.8.2-1+b1) ...
> > 
> > 
> > 
> > It looks like it was stuck at the restart of the systemd service:
> > 
> > # systemctl status nfs-kernel-server.service
> > ● nfs-server.service - NFS server and services
> >      Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; prese>
> >     Drop-In: /run/systemd/generator/nfs-server.service.d
> >              └─order-with-mounts.conf
> >      Active: activating (start-pre) since Tue 2025-01-21 12:40:52 CET; 10min ago
> >         Job: 97667
> >  Invocation: ced460d410fe4059b9e8781b35340d70
> >        Docs: man:rpc.nfsd(8)
> >              man:exportfs(8)
> >   Cntrl PID: 249039 (exportfs)
> >       Tasks: 3 (limit: 154102)
> >      Memory: 680K (peak: 2.5M)
> >         CPU: 10ms
> >      CGroup: /system.slice/nfs-server.service
> >              ├─239857 /usr/sbin/nfsdctl threads 0
> >              ├─239918 /usr/sbin/exportfs -au
> >              └─249039 /usr/sbin/exportfs -r
> > 
> > There was a 'nfsdctl' process in uninterruptible sleep (D):
> > 
> > $  ps -eldaf | grep nf[s]
> > 4 D root      239857       1  0  80   0 -   847 -      12:07 ?        00:00:00 /usr/sbin/nfsdctl threads 0
> > 5 S root      247511       1  0  80   0 -  1375 -      12:35 ?        00:00:00 /usr/sbin/nfsdcld
> > 
> > After about 30 min, since trying to kill PID 239857 obviously had no effect,
> > and I could not find any other strategy to restart nfs-kernel-server.service,
> > I had to reboot the box, thus causing many problems to all the NFS clients.
> > 
> > After reboot, I could issue:
> > 
> >   # aptitude --purge-unused safe-upgrade
> > 
> > which finally completed the upgrade (fixing the nfs-kernel-server package,
> > which was left in a partially configured state).
> > 
> > 
> > I have never seen anything like this before, and I have upgraded
> > nfs-kernel-server and related packages on Debian machines for quite
> > a long time.
> > Anyway, this should *not* happen during a system upgrade with
> > aptitude or apt!
> > 
> > I don't know whether bug [#992661] is related or not.
> > 
> > [#992661]: <https://bugs.debian.org/992661>
> > 
> > By looking at /var/log/kern.log , I see that a kernel BUG was traced
> > at the time when the 'nfsdctl' process got stuck in D state.
> > See the attached kern.log snippet.
> > 
> > Please investigate and fix the issue as soon as possible.
> > I really hope we can prevent this from happening again!
> > 
> > Thanks for your time and dedication.
> 
> So I'm not able to reproduce this on a current Debian unstable system
> mimicking the upgrade. *But* it is possible we have some races
> somehwere as recently discussed at our regular kernel team meeting.
> 
> We need first to find a way to trigger the issue in any case.

Upstream got an idea on what the problem is and posted a patch.
https://lore.kernel.org/linux-nfs/20250125-kdevops-v1-1-a76cf79127b8@kernel.org/

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#85293

FromFrancesco Poli <invernomuto@paranoici.org>
Date2025-01-26 18:10 +0100
Message-ID<K9ej0-c3P4-7@gated-at.bofh.it>
In reply to#85287

[Multipart message — attachments visible in raw view] — view raw

On Sun, 26 Jan 2025 13:57:05 +0100 Salvatore Bonaccorso wrote:

[...]
> Upstream got an idea on what the problem is and posted a patch.
> https://lore.kernel.org/linux-nfs/20250125-kdevops-v1-1-a76cf79127b8@kernel.org/

Good, thanks for the update and for reporting the issue upstream!
Really appreciated.

This sounds like good news: I really hope that it can prevent this
issue from happening again in the future.

Please let me know, once the patch enters a Debian kernel (I really
hope it can make it before trixie is released...).

Bye.   :-)


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web