The Tor Browser / file comparison
comparison: security/nss/tests/doc/platform_specific_problems
security/nss/tests/doc/platform_specific_problems
- changeset 0
- 6474c204b198
equal
deleted
inserted
replaced
| -1:000000000000 | 0:6b07ea674019 |
|---|---|
| 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 |
