mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"
Hi there, OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 did. This results in info log output in httpd: [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive shutdown (server myserver:443) Some background is given in https://github.com/openssl/openssl/issues/18866 They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to suppress this. Some other software now sets it with SSL_CTX_set_options(): - nginx https://github.com/nginx/nginx/commit/5155845ce4453a07d60e2ce43946c9181bc311fa - PHP https://github.com/php/php-src/pull/8558/commits/55be0f489e390d28892a07c32d45a404c62fc9f2 I suggest to adopt it, ie. set it if the option is available. WDYT? Best regards, Rainer
Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"
> Am 30.08.2023 um 13:21 schrieb Rainer Jung : > > Hi there, > > OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 > did. This results in info log output in httpd: > > [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL > Library Error: error:0A000126:SSL routines::unexpected eof while reading > [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] > [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive > shutdown (server myserver:443) > > Some background is given in > > https://github.com/openssl/openssl/issues/18866 > > They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to > suppress this. Some other software now sets it with SSL_CTX_set_options(): > > - nginx > > https://github.com/nginx/nginx/commit/5155845ce4453a07d60e2ce43946c9181bc311fa > > - PHP > > https://github.com/php/php-src/pull/8558/commits/55be0f489e390d28892a07c32d45a404c62fc9f2 > > I suggest to adopt it, ie. set it if the option is available. > > WDYT? +1 to setting this for our users sake. I withhold my opinion about this stupid OpenSSL change...oops. > > Best regards, > > Rainer
Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"
Am 30.08.23 um 13:50 schrieb Stefan Eissing via dev: Am 30.08.2023 um 13:21 schrieb Rainer Jung : Hi there, OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 did. This results in info log output in httpd: [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive shutdown (server myserver:443) Some background is given in https://github.com/openssl/openssl/issues/18866 They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to suppress this. Some other software now sets it with SSL_CTX_set_options(): - nginx https://github.com/nginx/nginx/commit/5155845ce4453a07d60e2ce43946c9181bc311fa - PHP https://github.com/php/php-src/pull/8558/commits/55be0f489e390d28892a07c32d45a404c62fc9f2 I suggest to adopt it, ie. set it if the option is available. WDYT? +1 to setting this for our users sake. I withhold my opinion about this stupid OpenSSL change...oops. Thanks for your feedback. I committed it to trunk in r1912015 and can revert if someone thinks its premature. Will propose for backport probably tomorrow. Best regards, Rainer
balancers bybusyness, bytraffic and byrequest thread/process safe issues
Hi, All the balancers have thread/process safe issues, but with bybusyness the effect is worse, basically a worker may stay with a busy count greater than zero even no request is being processed. busy is displayed in the balancer_handler() so users/customers will notice the value doesn't return to zero... If you run a load test the value of busy will increase by time and in all the workers When using bybusyness, having pics in the load and later no much load makes the lowest busy workers used and the ones with a wrong higher value not being used. In a test with 3 workers, I end with busy: worker1: 3 worker2: 0 worker3: 2 Doing the load test several time the buys values are increasing in all workers. I am wondering is we could end with something like: worker1: 1000 worker2: 0 worker3: 1000 in this case bybusyness will send all the load to worker2 until we reach 1000 simultaneous request on worker2... Obvious that looks bad. How to fix that? 1 - reset the busy using a watchdog and elected (or transferred+read) unchanged for some time (using one of timeout we have on workers). 2 - warn in the docs that bybusyness is not the best choice for loadbalancing. 3 - create another balancer that just choose random a worker. -- Cheers Jean-Frederic
Re: balancers bybusyness, bytraffic and byrequest thread/process safe issues
Hi JFC, I have not checked ur current code, but the topic reminds me of our history in mod_jk land. There we switched the counters to atomics were available. The other problematic part could be how to handle process local counters versus global counters. Busyness was especially problematic for mod_jk as well, because we never deremented below zero if we lost increments, but if we lost decrements the counters stayed elevated. I think there we now have no longer such problems. Best regards, Rainer Am 30.08.23 um 17:19 schrieb jean-frederic clere: Hi, All the balancers have thread/process safe issues, but with bybusyness the effect is worse, basically a worker may stay with a busy count greater than zero even no request is being processed. busy is displayed in the balancer_handler() so users/customers will notice the value doesn't return to zero... If you run a load test the value of busy will increase by time and in all the workers When using bybusyness, having pics in the load and later no much load makes the lowest busy workers used and the ones with a wrong higher value not being used. In a test with 3 workers, I end with busy: worker1: 3 worker2: 0 worker3: 2 Doing the load test several time the buys values are increasing in all workers. I am wondering is we could end with something like: worker1: 1000 worker2: 0 worker3: 1000 in this case bybusyness will send all the load to worker2 until we reach 1000 simultaneous request on worker2... Obvious that looks bad. How to fix that? 1 - reset the busy using a watchdog and elected (or transferred+read) unchanged for some time (using one of timeout we have on workers). 2 - warn in the docs that bybusyness is not the best choice for loadbalancing. 3 - create another balancer that just choose random a worker.
