Hi Cyril, Hi Lukas,
On Mon, Jun 06, 2016 at 08:21:46PM +0200, Cyril Bonté wrote:
> Hi Lukas,
>
> I add Malcolm and Simon to the thread.
>
> Le 06/06/2016 à 08:36, Lukas Erlacher a écrit :
> >Additional info: The output only ends up in the *first* client connection.
> >
> >Talking about this with some colleagues we're now theorizing that stdout
> >goes to fd 1 and fd 1 is also the first client connection socket. Might be
> >helpful for tracking this down.
>
> After doing a quick test, I can confirm I can reproduce the issue (once
> working in daemon mode).
>
> Simon, do you have time to work on a fix ? or should someone else do ? (I
> think I'll be available to work on this, but only by the end of the week)
>
> Also Malcolm, as I remember you are using this feature, be aware that you
> may hit the issue too.
looking over the code a little the theory regarding fd 1 seems entirely
plausible as stdout, along with stdin and stdin, may be be closed
in haproxy.c:main()
It seems to me that if the case where they were closed, and thus fd 1 and 2
may be used for other purposes, it would be prudent to redirect fd 1 and 2
to "/dev/null".
One problem I see with this is that if haproxy is running in a chroot
and /dev/null is not present then open() will fail.
Lukas, would it be possible for you to test the following
(I have only compile tested it) ?
diff --git a/src/checks.c b/src/checks.c
index c4ac947b6051..eca7df62522f 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -1836,6 +1836,16 @@ 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);
+
+ if (open("/dev/null", 0, O_WRONLY) || open("/dev/null",
0, O_WRONLY)) {
+ exit (-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);
