diff options
Diffstat (limited to 'security/nss/tests/doc/platform_specific_problems')
| -rw-r--r-- | security/nss/tests/doc/platform_specific_problems | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/security/nss/tests/doc/platform_specific_problems b/security/nss/tests/doc/platform_specific_problems new file mode 100644 index 000000000..92a22ca03 --- /dev/null +++ b/security/nss/tests/doc/platform_specific_problems @@ -0,0 +1,110 @@ +I will, eventually convert all files here to html - just right now I have no +time to do it. Anyone who'd like to - please feel free, mail me the file and +I will check it in +sonmi@netscape.com + + +The NSS 3.1 SSL Stress Tests fail for me on FreeBSD 3.5. The end of the output +of './ssl.sh stress' looks like this: + +********************* Stress Test **************************** +********************* Stress SSL2 RC4 128 with MD5 **************************** +selfserv -p 8443 -d +/local/llennox/NSS-PSM/mozilla/tests_results/security/conrail.20/server -n +conrail.cs.columbia.edu -w nss -i /tmp/tests_pid.5505 & strsclnt -p 8443 -d . -w nss -c 1000 -C A conrail.cs.columbia.edu +strsclnt: -- SSL: Server Certificate Validated. +strsclnt: PR_NewTCPSocket returned error -5974: +Insufficient system resources. +Terminated +********************* Stress SSL3 RC4 128 with MD5 **************************** +selfserv -p 8443 -d +/local/llennox/NSS-PSM/mozilla/tests_results/security/conrail.20/server -n +conrail.cs.columbia.edu -w nss -i /tmp/tests_pid.5505 & strsclnt -p 8443 -d . -w nss -c 1000 -C c conrail.cs.columbia.edu +strsclnt: -- SSL: Server Certificate Validated. +strsclnt: PR_NewTCPSocket returned error -5974: +Insufficient system resources. +Terminated + +Running ktrace on the process (ktrace is a system-call tracer, the equivalent of +Linux's strace) reveals that socket() failed with ENOBUFS after it was called +for the 953rd time for the first test, and it failed after the 27th time it was +called for the second test. + +The failure is consistent, both for debug and optimized builds; I haven't tested +to see whether the count of socket() failures is consistent. + +All the other NSS tests pass successfully. + + +------- Additional Comments From Nelson Bolyard 2000-11-01 23:08 ------- + +I see no indication of any error on NSS's part from this description. +It sounds like an OS kernel configuration problem on the +submittor's system. The stress test is just that. It stresses +the server by pounding it with SSL connections. Apparently this +test exhausts some kernel resource on the submittor's system. + +The only change to NSS that might be beneficial to this test +would be to respond to this error by waiting and trying again +for some limited number of times, rather than immediately +treating it as a fatal error. + +However, while such a change might make the test appear to pass, +it would merely be hiding a very serious problem, namely, +chronic system resource exhaustion. + +So, I suggest that, in this case, the failure serves the useful +purpose of revealing the system problem, which needs to be +cured apart from any changes to NSS. + +I'll leave this bug open for a few more days, to give others +a chance to persuade me that some NSS change would and should +solve this problem. + + +------- Additional Comments From Jonathan Lennox 2000-11-02 13:13 ------- + +Okay, some more investigation leads me to agree with you. What's happening is +that the TCP connections from the stress test stick around in TIME_WAIT for two +minutes; my kernel is only configured to support 1064 simultaneous open sockets, +which isn't enough for the 2K sockets opened by the stress test plus the 100 or +so normally in use on my system. + +So I'd just suggest adding a note to the NSS test webpage to the effect of "The +SSL stress test opens 2,048 TCP connections in quick succession. Kernel data +structures may remain allocated for these connections for up to two minutes. +Some systems may not be configured to allow this many simulatenous connections +by default; if the stress tests fail, try increasing the number of simultaneous +sockets supported." + +On FreeBSD, you can display the number of simultaneous sockets with the command + sysctl kern.ipc.maxsockets +which on my system returns 1064. + +It looks like this can be fixed with the kernel config option + options NMBCLUSTERS=[something-large] +or by increasing the 'maxusers' parameter. + +It looks like more recent FreeBSD implementations still have this limitation, +and the same solutions apply, plus you can alternatively specify the maxsockets +parameter in the boot loader. + + +--------------------------------- + +hpux HP-UX hp64 B.11.00 A 9000/800 2014971275 two-user license + +we had to change following kernelparameters to make our tests pass + +1. maxfiles. old value = 60. new value = 100. +2. nkthread. old value = 499. new value = 1328. +3. max_thread_proc. old value = 64. new value = 512. +4. maxusers. old value = 32. new value = 64. +5. maxuprc. old value = 75. new value = 512. +6. nproc. old formula = 20+8*MAXUSERS, which evaluated to 276. + new value (note: not a formula) = 750. + +A few other kernel parameters were also changed automatically +as a result of the above changes. + + |