Ralph Boehme
2023-Feb-01 10:38 UTC
[Samba] Hanging, uninterruptible smbd-process in "D"-state
On 2/1/23 10:18, Rainer Krienke via samba wrote:> Since the process is in state "D" its not killable and the only > solution is a reboot of the samba server itself which of course is an > "ugly" solution.as for "D" state: ask the the kernel, that's out of Samba's control. You can start with a /proc/PID/stack to find out where in the kernel the process is stuck, my guess would be somewhere in the NFS code. As pointed out by Rowland, resharing NFS should be avoided by all means. It will work initially and then it will bite you hard at some point. :) -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20230201/fe636904/OpenPGP_signature.sig>
Rainer Krienke
2023-Feb-01 11:54 UTC
[Samba] Hanging, uninterruptible smbd-process in "D"-state
Hi, tanks for the answer. Since /proc/<PID>/stack is a stack the topmost element should be the task where it got stuck which is: rwsem_down_write_slowpath which waits for getting a write lock semaphore: cat /proc/10193/stack [<0>] rwsem_down_write_slowpath+0x2e2/0x620 [<0>] nfs_rmdir+0x117/0x1b0 [nfs] [<0>] vfs_rmdir+0x7c/0x1b0 [<0>] do_rmdir+0x216/0x230 [<0>] do_syscall_64+0x5b/0x80 [<0>] entry_SYSCALL_64_after_hwframe+0x61/0xcb The strange is that all of a sudden this setup (nfsserver+samba-client) fails, where it has worked for 10 years without any trouble. Thanks Rainer Am 01.02.23 um 11:38 schrieb Ralph Boehme via samba:> On 2/1/23 10:18, Rainer Krienke via samba wrote: >> Since the process is in state "D" its not killable and the only >> solution is a reboot of the samba server itself which of course is an >> "ugly" solution. > > as for "D" state: ask the the kernel, that's out of Samba's control. You > can start with a /proc/PID/stack to find out where in the kernel the > process is stuck, my guess would be somewhere in the NFS code. > > As pointed out by Rowland, resharing NFS should be avoided by all means. > It will work initially and then it will bite you hard at some point. :) > > -slow > >-- Rainer Krienke, Uni Koblenz, IT-Services, A22, Universitaetsstrasse 1 56070 Koblenz, Tel: +49261287 1312 Fax +49261287 100 1312 Web: http://userpages.uni-koblenz.de/~krienke PGP: http://userpages.uni-koblenz.de/~krienke/mypgp.html