GĂ©rard GUEVEL
2024-Jan-08 11:47 UTC
[Samba] fuser calls create zombie processes on samba file server
Hello, I want to relate a Samba client issue which could hide a Samba server issue. For my own, three machines are involved : A Samba version 4.18.6-Debian Active Directory DC server. A Samba version 4.13.13-Debian Domain Member FILE server. An Ubuntu 20.04.6 LTS BENCH server with a CIFS share mounted on FILE server. A BENCH application run many threads which have to check the opened files each second using a python fuser call. After about 5 hours, the FILE server claims that too many files are opened and the max open files limit (16384) is reached. The FILE server does not crash but remains exhausted to serve all other clients. We found that if a first fuser call is running while a second one is launched then the first opened process is never closed on the FILE server. So each second, we create a zombie Samba process and reach the OS limit after about 5 heures. Our workaround is to flock (mutex) the fuser call to avoid server conflicting calls. I don?t understand why concurrent fuser calls can corrupt the server. Thanks for any explaination. Gerard GUEVEL
Rowland Penny
2024-Jan-08 14:17 UTC
[Samba] fuser calls create zombie processes on samba file server
On Mon, 8 Jan 2024 12:47:45 +0100 G?rard GUEVEL via samba <samba at lists.samba.org> wrote:> Hello, > > > > I want to relate a Samba client issue which could hide a Samba server > issue. > > > > For my own, three machines are involved : > > A Samba version 4.18.6-Debian Active Directory DC server. > > A Samba version 4.13.13-Debian Domain Member FILE server. > > An Ubuntu 20.04.6 LTS BENCH server with a CIFS share mounted on FILE > server. > > > > A BENCH application run many threads which have to check the opened > files each > > second using a python fuser call. After about 5 hours, the FILE server > claims that > > too many files are opened and the max open files limit (16384) is > reached. > > The FILE server does not crash but remains exhausted to serve all > other clients. >Try setting 'deadtime' in your smb.conf, it defaults to 10080 minutes, try something like 10 as a starting point, see if that helps. Rowland