Re: [BUG] NSE/Nsock filehandle exhaustion

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 30 Aug 2007 23:13:01 +0200
majek04 <majek04+nmap-dev () gmail com> wrote:

> Well, of course you're right. It means that we have to keep threshold
> pretty high (to avoid deadlocks). I'm not sure if there is a need of
> tweaking this threshold at runtime. Maybe it should be hardcoded to read
> getrlimit(RLIMIT_NOFILE) at nmap start?
>
> Should we hardcode nsock descriptors threshold?
> or maybe it should be set to --max-parallelism?
> or set to getrlimit(RLIMIT_NOFILE)*75%?
>
>
> Marek Majkowski

Well RLIMIT_NOFILE isn't the direct cause of the assert() failure.  My
file limit was 1024, in which case, Nmap would crash when it ran out of
file descriptors.  I increased my file descriptor max to 10240 which
revealed the problem with NSE/Nsock at around 1024 descriptors.

To illustrate this, here's a quick and dirty program:

#include <stdio.h>
#include <sys/resource.h>

int main (void) {
  struct rlimit rlim;

  getrlimit(RLIMIT_NOFILE, &rlim);

  fprintf(stdout, "RLIMIT_NOFILE is %d.\n", rlim.rlim_max);

  return 0;
}


$ gcc -o rlimit rlimit.c
$ sudo ./rlimit
RLIMIT_NOFILE is 10240.

Clearly, setting the max to some factor of RLIMIT_NOFILE isn't reliable.  I
also think you're right that we need to keep the max relatively high to
avoid deadlocking a script.  Maybe we should just set it at 128 and forget
about it?

Although I haven't looked, I suspect that there is a problem with Nsock
hardcoding a max at 1024 and then not failing gracefully when it is
reached.  Perhaps Nsock should read RLIMIT_NOFILE to scale to the system
max and then NSE can use some percentage of RLIMIT_NOFILE (or some other
value like --max-parallelism with some minimum like 16).

Thanks again for your work on this!

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG1zjQqaGPzAsl94IRAjFCAKCPwIO5jwUWY47OQBi77u2mkCjjAQCfUvln
EwquoXKyzKxG5Gob3O6+11U=
=8B4N
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org