Ah, this is fun :D
Running this haproxy built from git:
> erlacher@vmrbg81:~/haproxy$ sudo ./haproxy -vv
> HA-Proxy version 1.7-dev3-4b788f-35 2016/06/08
> Copyright 2000-2016 Willy Tarreau <wi...@haproxy.org>
>
> Build options :
> TARGET = linux2628
> CPU = generic
> CC = gcc
> CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1
>
> Default settings :
> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Encrypted password support via crypt(3): yes
> Built with zlib version : 1.2.8
> Compression algorithms supported : identity("identity"), deflate("deflate"),
> raw-deflate("deflate"), gzip("gzip")
> Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports prefer-server-ciphers : yes
> Built with PCRE version : 8.31 2012-07-06
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built without Lua support
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
> IP_FREEBIND
>
> Available polling systems :
> epoll : pref=300, test result OK
> poll : pref=200, test result OK
> select : pref=150, test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available filters :
> [COMP] compression
> [TRACE] trace
Running this commandline:
> erlacher@vmrbg81:~/haproxy$ sudo ./haproxy -d -f /etc/haproxy/haproxy.cfg
>
>
>
Results in the ldapcheck output going out to just regular stdout. So I'll have
to run haproxy daemonized to reproduce the problem...
> erlacher@vmrbg81:~/haproxy$ sudo ./haproxy -f /etc/haproxy/haproxy.cfg
This results in the expected erroneous output on the first client connection.
Now to apply the patch and rebuild...
Running haproxy with -d still gives the check output on haproxy stdout, which
is ok I suppose.
Running haproxy daemonized... gives no check output. Good!
So from this small test I believe the patch works.
Best,
Luke
On 08.06.2016 03:17, Simon Horman wrote:
> On Tue, Jun 07, 2016 at 08:18:21PM +0200, Willy Tarreau wrote:
>> On Tue, Jun 07, 2016 at 12:01:31PM +0200, Benoit Garnier wrote:
>>> You can always open /dev/null before chrooting and dup() it into FD 0 and 1
>>> after chroot() has been called.
>>
>> I'd be more tempted to simply close those FDs after the fork(). That
>> may improve the ability to detect faulty scripts which try to dump
>> GBs of data.
>>
>> A very long time ago I've seen a health check perform an LDAP search
>> retrieving all the hundreds of thousands of members of a group, and
>> the people in charge for the server were complaining that the health
>> checks were hurting the server... Better have the script fail with a
>> broken pipe in this case.
>>
>> Just a suggestion.
>
> Thanks, I think that is reasonable. I particularly like its simplicity.
>
> Lukas, could you try this?
>
> diff --git a/src/checks.c b/src/checks.c
> index c4ac947b6051..e65d28f7c3c6 100644
> --- a/src/checks.c
> +++ b/src/checks.c
> @@ -1836,6 +1836,12 @@ static int connect_proc_chk(struct task *t)
> if (pid == 0) {
> /* Child */
> extern char **environ;
> +
> + if ((global.mode & MODE_QUIET) && !(global.mode &
> MODE_VERBOSE)) {
> + close(0);
> + close(1);
> + }
> +
> environ = check->envp;
> extchk_setenv(check, EXTCHK_HAPROXY_SERVER_CURCONN,
> ultoa_r(s->cur_sess, buf, sizeof(buf)));
> execvp(px->check_command, check->argv);
>
--
Mit freundlichen Gruessen,
Lukas Erlacher
--
Rechnerbetriebsgruppe der Fakultäten Mathematik und Informatik
Raum 00.05.042
Tel. 089-289-18258
erlac...@in.tum.de
Technische Universität München - Boltzmannstr. 3 - 85748 Garching
smime.p7s
Description: S/MIME Cryptographic Signature
