Seamless reloads: file descriptors utilization in LUA
Hello, 1. When in LUA - I open some socket and left it unclosed (even UDP-sender socket) - Or open some files (for example, I use LUA-maxmind lib that opens GEO-DB file) It is never destroyed. With each reload amount of used descriptors grows and finally reaches limits. According to "lsof", all sockets and descriptors are belongs to master process and all new worker processes. Should be some way to destroy it during reload or to really use advantages of such transfers. Tested with Haproxy 1.8.12 2. Since haproxy has LUA, user could have needs for file descriptors that is impossible to count. Is there any real reason to keep "auto-calculated" ulimit-n option with very low values, based just on connection limits? Of cause, it is easy to set (for those who read docs very carefully =)), but some extra value could cover a few more cases "from the box", also making a bit less critical FD-related bugs. At least some warning in docs for this option should be useful. P.s. Looks like FD-limit was the reason for 503 with NOSRV and SC-flag that I've described here - https://www.mail-archive.com/haproxy@formilux.org/msg30405.html -- Wert Revon
Re: patch for enabling gitlab-ci
No interest? On Fri, Jul 13, 2018, 2:58 PM Илья Шипицин wrote: > Hello, > > I created a patch which will allow anyone to build CI > using "CI for external repo" + mirroring on https://gitlab.com > > Cheers, > Ilya Shipitsin >
Re: TLS handshake works with certificate name mismatch using "verify required" and "verifyhost"
Hello Martin, > we have a strange situation with our HAProxy, running on Version 1.8.8 with > OpenSSL. Please share the output of haproxy -vv. Did you build openssl yourself or is this a distribution provided openssl lib? I am asking because build issues can lead to very strange behavior. > server BACKEND1-server 10.1.1.1:443 check inter 30s verify required ssl > verifyhost *.foo.bar *.foo.bar is not a valid hostname. It is a valid wildcard representation in a cert's SAN, yes, but not a hostname. Use real hostname for verifyhost instead, like www.foo.bar Also, lets confirm the backend is really configured as per expectations, by running requests via curl from the haproxy box: This should work: curl -v --cacert /etc/haproxy/certs/backend-ca-certificates.crt --resolve www.foo.bar:443:10.1.1.1 https://www.foo.bar/ This should fail: curl -v --cacert /etc/haproxy/certs/backend-ca-certificates.crt --resolve www.foo.fail:443:10.1.1.1 https://www.foo.fail/ cheers, lukas
