On Tue, 11 Jul 2023, Chuck Lever III wrote: > > On Jul 10, 2023, at 6:18 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > What do you think of removing the ability to stop an nfsd thread by > > sending it a signal. Note that this doesn't apply to lockd or to nfsv4 > > callback threads. And nfs-utils never relies on this. > > I'm keen. It would make this patch a lot simpler. > > I agree the code base would be cleaner for it. > > But I'm the new kid. I'm not really sure if this is > part of a kernel - user space API that we mustn't > alter, or whether it's something that was added but > never used, or .... > > I can sniff around to get a better understanding. Once upon a time it was the only way to kill the threads. There was a syscall which let you start some threads. You couldn't change the number of threads, but you could kill them. And shutdown always kills processes, so letting nfsd threads be killed meant that would be removed at system shutdown. When I added the ability to dynamically change the number of threads it made sense that we could set the number to zero, and then to use that functionality to shut down the nfs server. So the /etc/init.d/nfsd script changed from "killall -9 nfsd" or whatever it was to "rpc.nfsd 0". But it didn't seem sensible to remove the "kill" functionality until after a transition process, and I never thought the schedule a formal deprecation. So it just stayed... The more I think about it, the more I am in favour of removing it. I don't think any other kernel threads can be killed. nfsd doesn't need to be special. Maybe I'll post a patch which just does that. NeilBrown
