Nmap Development mailing list archives
Re: [BUG] NSE/Nsock filehandle exhaustion
From: majek04 <majek04+nmap-dev () gmail com>
Date: Thu, 30 Aug 2007 23:13:01 +0200
On 8/30/07, Brandon Enright <bmenrigh () ucsd edu> wrote:
(It can run two times lua_yield on lua thread, but it seems that it isn't bad, although it's not theoretically proper I think),I haven't been able to get it to crash so with some tweaking and further testing, should probably be included.
Hurray :)
Your patch solves the Nsock handle problem in a totally different way than Stoiko's patch but I don't think that means that one or the other should be applied. They BOTH should be applied.
I'm not sure if Stoiko's patch breaks the equality of all lua threads. As far as I understand, one thread (the latest started?) is going to be always served first. On the other hand, it shouldn't really matter.
With your patch, when the NSE loop starts, the NSOCK handles climb to 768 in a few seconds and stay pretty pegged there until the NSE scanning finishes. When this happens, the following lines are printed by the thousands: NSOCK: thread unqueued 0xa981f0
They are just stupid debugging messages, I forgot to remove them.
The one concern I have with this patch is what would happen if the limit were set to 1 and then a single NSE script tried to make 2 sockets and connect on both before doing anything else. Am I right in assuming that this script would deadlock because the script wouldn't be able to finish and close the first without the second being made to allow it to continue? Let me know if this doesn't make sense or I'm just stupid.
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 _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- [BUG] NSE/Nsock filehandle exhaustion Brandon Enright (Aug 27)
- Re: [BUG] NSE/Nsock filehandle exhaustion Stoiko Ivanov (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion Brandon Enright (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion majek04 (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion Brandon Enright (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion majek04 (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion Brandon Enright (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion Brandon Enright (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion Fyodor (Aug 30)
- Re: [BUG] NSE/Nsock filehandle exhaustion Stoiko Ivanov (Aug 30)