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