platform_specific_problems (4739B)
1 I will, eventually convert all files here to html - just right now I have no 2 time to do it. Anyone who'd like to - please feel free, mail me the file and 3 I will check it in 4 sonmi@netscape.com 5 6 7 The NSS 3.1 SSL Stress Tests fail for me on FreeBSD 3.5. The end of the output 8 of './ssl.sh stress' looks like this: 9 10 ********************* Stress Test **************************** 11 ********************* Stress SSL2 RC4 128 with MD5 **************************** 12 selfserv -p 8443 -d 13 /local/llennox/NSS-PSM/mozilla/tests_results/security/conrail.20/server -n 14 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 15 strsclnt: -- SSL: Server Certificate Validated. 16 strsclnt: PR_NewTCPSocket returned error -5974: 17 Insufficient system resources. 18 Terminated 19 ********************* Stress SSL3 RC4 128 with MD5 **************************** 20 selfserv -p 8443 -d 21 /local/llennox/NSS-PSM/mozilla/tests_results/security/conrail.20/server -n 22 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 23 strsclnt: -- SSL: Server Certificate Validated. 24 strsclnt: PR_NewTCPSocket returned error -5974: 25 Insufficient system resources. 26 Terminated 27 28 Running ktrace on the process (ktrace is a system-call tracer, the equivalent of 29 Linux's strace) reveals that socket() failed with ENOBUFS after it was called 30 for the 953rd time for the first test, and it failed after the 27th time it was 31 called for the second test. 32 33 The failure is consistent, both for debug and optimized builds; I haven't tested 34 to see whether the count of socket() failures is consistent. 35 36 All the other NSS tests pass successfully. 37 38 39 ------- Additional Comments From Nelson Bolyard 2000-11-01 23:08 ------- 40 41 I see no indication of any error on NSS's part from this description. 42 It sounds like an OS kernel configuration problem on the 43 submittor's system. The stress test is just that. It stresses 44 the server by pounding it with SSL connections. Apparently this 45 test exhausts some kernel resource on the submittor's system. 46 47 The only change to NSS that might be beneficial to this test 48 would be to respond to this error by waiting and trying again 49 for some limited number of times, rather than immediately 50 treating it as a fatal error. 51 52 However, while such a change might make the test appear to pass, 53 it would merely be hiding a very serious problem, namely, 54 chronic system resource exhaustion. 55 56 So, I suggest that, in this case, the failure serves the useful 57 purpose of revealing the system problem, which needs to be 58 cured apart from any changes to NSS. 59 60 I'll leave this bug open for a few more days, to give others 61 a chance to persuade me that some NSS change would and should 62 solve this problem. 63 64 65 ------- Additional Comments From Jonathan Lennox 2000-11-02 13:13 ------- 66 67 Okay, some more investigation leads me to agree with you. What's happening is 68 that the TCP connections from the stress test stick around in TIME_WAIT for two 69 minutes; my kernel is only configured to support 1064 simultaneous open sockets, 70 which isn't enough for the 2K sockets opened by the stress test plus the 100 or 71 so normally in use on my system. 72 73 So I'd just suggest adding a note to the NSS test webpage to the effect of "The 74 SSL stress test opens 2,048 TCP connections in quick succession. Kernel data 75 structures may remain allocated for these connections for up to two minutes. 76 Some systems may not be configured to allow this many simulatenous connections 77 by default; if the stress tests fail, try increasing the number of simultaneous 78 sockets supported." 79 80 On FreeBSD, you can display the number of simultaneous sockets with the command 81 sysctl kern.ipc.maxsockets 82 which on my system returns 1064. 83 84 It looks like this can be fixed with the kernel config option 85 options NMBCLUSTERS=[something-large] 86 or by increasing the 'maxusers' parameter. 87 88 It looks like more recent FreeBSD implementations still have this limitation, 89 and the same solutions apply, plus you can alternatively specify the maxsockets 90 parameter in the boot loader. 91 92 93 --------------------------------- 94 95 hpux HP-UX hp64 B.11.00 A 9000/800 2014971275 two-user license 96 97 we had to change following kernelparameters to make our tests pass 98 99 1. maxfiles. old value = 60. new value = 100. 100 2. nkthread. old value = 499. new value = 1328. 101 3. max_thread_proc. old value = 64. new value = 512. 102 4. maxusers. old value = 32. new value = 64. 103 5. maxuprc. old value = 75. new value = 512. 104 6. nproc. old formula = 20+8*MAXUSERS, which evaluated to 276. 105 new value (note: not a formula) = 750. 106 107 A few other kernel parameters were also changed automatically 108 as a result of the above changes. 109 110