max smbd processes

[Shlomi Yaakobovich]

===
Hello people of samba-technical - this mail is going out by proxy so I can avoid being spammed to Death :). (Thanks Shlomi!)

I have a question regarding the connection counter - from smbd/server.c :
                      
if (allowable_number_of_smbd_processes() && smbd_server_fd() != -1 && sys_fork()==0) {
                                /* Child code ... */

smbd_process_limit() isn't called until much later (in the CVS it appears as if it's called on the first packet)

This seems to be open to a variety of races - smbd_process_limit() is the function that increments the counter in connections.tdb - even if you move the smbd_process_limit() call to right after the fork (as we have) it still doesn't seem to eliminate the basic race- assume, if you will, that only the parent code runs for a while - all the while having thousands of requests, it would fork a new request every time and since the counter is never incremented it would happily move on to the fork and consume system resources (without obeying the limit specified in smb.conf).

So my questions are:

A. Am I missing something fundamental?
B. Is there any harm in moving smbd_process_limit() instead of allowable_number_of_smbd_processes(), storing a variable that is the return code of the fork, and decrementing the smbd count if fork fails? That would make it immune to these races.

Also - as a side note - it seems as if the decrementing of connection count is normally done by exit_server() and/or smb_panic2() - if the process is killed with a kill -9 then the counter is never decremented disallowing legitimate users access. This could, in theory, be handled by using a global counter in the parent smbd and decrementing it on SIGCHLD. Is there a reason I'm missing for all this bookkeeping being done in a TDB? Perhaps subtle races between two smbd's dying at once?

Thanks,
Nir.

===

Shlomi