Re: Lots of mail from email alert on 1.9.x
Op 13-01-19 om 18:47 schreef Willy Tarreau: > Hi Olivier, > > On Sun, Jan 13, 2019 at 06:40:56PM +0100, Olivier Houchard wrote: >>> Indeed, this function should not have any special effect in this case, >>> it is needed to prepend this at the beginning of chk_report_conn_err() : >>> >>> if (!check->server) >>> return; >>> >>> We need to make sure that check->server is properly tested everywhere. >>> With a bit of luck this one was the only remnant. >>> >> I'd rather just avoid calling dns_trigger_resolution() if there's no server, >> it seems it is the only use of check->server in chk_report_conn_err(), so >> that set_server_check_status() is call, and the check's status and result >> may be updated. > OK, that's fine with me as well, I hesitated between the two. > >> Not sure it is really needed, but I'd rather not offend the Check Gods. > :-) > >> The attached patches are updated to od just that. > Thank you. I'll merge them tomorrow. The ugliness of this code tells me > it's becoming urgent to perform a serious lifting to the whole checks > code :-/ > > Thanks, > Willy > Sorry for the late reply, have been struck by flu. I can confirm that with version 1.9.2 all is fine with the e-mail alerts again. Thanks all.
Re: Lots of mail from email alert on 1.9.x
Hi Olivier, On Sun, Jan 13, 2019 at 06:40:56PM +0100, Olivier Houchard wrote: > > Indeed, this function should not have any special effect in this case, > > it is needed to prepend this at the beginning of chk_report_conn_err() : > > > > if (!check->server) > > return; > > > > We need to make sure that check->server is properly tested everywhere. > > With a bit of luck this one was the only remnant. > > > > I'd rather just avoid calling dns_trigger_resolution() if there's no server, > it seems it is the only use of check->server in chk_report_conn_err(), so > that set_server_check_status() is call, and the check's status and result > may be updated. OK, that's fine with me as well, I hesitated between the two. > Not sure it is really needed, but I'd rather not offend the Check Gods. :-) > The attached patches are updated to od just that. Thank you. I'll merge them tomorrow. The ugliness of this code tells me it's becoming urgent to perform a serious lifting to the whole checks code :-/ Thanks, Willy
Re: Lots of mail from email alert on 1.9.x
Hi,
On Sat, Jan 12, 2019 at 01:11:29PM +0100, Willy Tarreau wrote:
> Hi Pieter,
>
> On Sat, Jan 12, 2019 at 01:00:33AM +0100, PiBa-NL wrote:
> > Thanks for this 'change in behavior' ;). Indeed the mailbomb is fixed, and
> > it seems the expected mails get generated and delivered, but a segfault also
> > happens on occasion. Not with the regtest as it was, but with a few minor
> > modifications (adding a unreachable mailserver, and giving it a little more
> > time seems to be the most reliable reproduction a.t.m.) it will crash
> > consistently after 11 seconds.. So i guess the patch needs a bit more
> > tweaking.
> >
> > Regards,
> > PiBa-NL (Pieter)
> >
> > Core was generated by `haproxy -d -f /tmp/vtc.37274.4b8a1a3a/h1/cfg'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 0x00500955 in chk_report_conn_err (check=0x802616a10,
> > errno_bck=0, expired=1) at src/checks.c:689
> > 689 dns_trigger_resolution(check->server->dns_requester);
> > (gdb) bt full
> > #0 0x00500955 in chk_report_conn_err (check=0x802616a10,
> > errno_bck=0, expired=1) at src/checks.c:689
>
> Indeed, this function should not have any special effect in this case,
> it is needed to prepend this at the beginning of chk_report_conn_err() :
>
> if (!check->server)
> return;
>
> We need to make sure that check->server is properly tested everywhere.
> With a bit of luck this one was the only remnant.
>
I'd rather just avoid calling dns_trigger_resolution() if there's no server,
it seems it is the only use of check->server in chk_report_conn_err(), so
that set_server_check_status() is call, and the check's status and result
may be updated. Not sure it is really needed, but I'd rather not offend
the Check Gods.
The attached patches are updated to od just that.
Regards,
Olivier
>From 7e7b41cac480029c5fd93338dd86a875fee0b5a7 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Fri, 11 Jan 2019 18:17:17 +0100
Subject: [PATCH 1/2] MINOR: checks: Store the proxy in checks.
Instead of assuming we have a server, store the proxy directly in struct
check, and use it instead of s->server.
This should be a no-op for now, but will be useful later when we change
mail checks to avoid having a server.
This should be backported to 1.9.
---
include/types/checks.h | 1 +
src/checks.c | 32 +---
src/server.c | 1 +
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/include/types/checks.h b/include/types/checks.h
index 6346fe33..f89abcba 100644
--- a/include/types/checks.h
+++ b/include/types/checks.h
@@ -180,6 +180,7 @@ struct check {
int send_string_len;/* length of agent command
string */
char *send_string; /* optionally send a string
when connecting to the agent */
struct server *server; /* back-pointer to server */
+ struct proxy *proxy;/* proxy to be used */
char **argv;/* the arguments to use if
running a process-based check */
char **envp;/* the environment to use if
running a process-based check */
struct pid_list *curpid;/* entry in pid_list used for
current process-based test, or -1 if not in test */
diff --git a/src/checks.c b/src/checks.c
index 4baaf9fc..edb61b4f 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -2124,7 +2124,7 @@ static struct task *process_chk_proc(struct task *t, void
*context, unsigned sho
static struct task *process_chk_conn(struct task *t, void *context, unsigned
short state)
{
struct check *check = context;
- struct server *s = check->server;
+ struct proxy *proxy = check->proxy;
struct conn_stream *cs = check->cs;
struct connection *conn = cs_conn(cs);
int rv;
@@ -2142,7 +2142,7 @@ static struct task *process_chk_conn(struct task *t, void
*context, unsigned sho
* is disabled.
*/
if (((check->state & (CHK_ST_ENABLED | CHK_ST_PAUSED)) !=
CHK_ST_ENABLED) ||
- s->proxy->state == PR_STSTOPPED)
+ proxy->state == PR_STSTOPPED)
goto reschedule;
/* we'll initiate a new check */
@@ -2167,8 +2167,8 @@ static struct task *process_chk_conn(struct task *t, void
*context, unsigned sho
*/
t->expire = tick_add(now_ms, MS_TO_TICKS(check->inter));
- if (s->proxy->timeout.check &&
s->proxy->timeout.connect) {
- int t_con = tick_add(now_ms,
s->proxy->timeout.connect);
+ if (proxy->timeout.check && proxy->timeout.connect) {
+ int t_con = tick_add(now_ms,
proxy->timeout.connect);
t->expire = tick_first(t->expire, t_con);
Re: Lots of mail from email alert on 1.9.x
Hi Pieter, On Sat, Jan 12, 2019 at 09:30:39PM +0100, PiBa-NL wrote: > Hi Willy, Olivier, > > Op 12-1-2019 om 13:11 schreef Willy Tarreau: > > Hi Pieter, > > > > it is needed to prepend this at the beginning of chk_report_conn_err() : > > > > if (!check->server) > > return; > > > > We need to make sure that check->server is properly tested everywhere. > > With a bit of luck this one was the only remnant. > > > > Thanks! > > Willy > > With the check above added, mail alerts seem to work properly here, or just > as good as they used to anyhow. Great, thank you! > Once the patches and above addition get committed, that leaves the other > 'low priority' issue of needing a short timeout to send the exact amount of > 'expected' mails. > EXPECT resp.http.mailsreceived (10) == "16" failed > To be honest i only noticed it due to making the regtest, and > double-checking what to expect.. When i validated mails on my actual > environment it seems to work properly. (Though the server i took out to test > has a health-check with a 60 second interval..) Anyhow its been like this > for years afaik, i guess it wont matter much if stays like this a bit > longer. I think it'll indeed stay for a while given that I'd like to focus a bit more on collecting the remaining important stuff for 1.9.2. Cheers, Willy
Re: Lots of mail from email alert on 1.9.x
Hi Willy, Olivier, Op 12-1-2019 om 13:11 schreef Willy Tarreau: Hi Pieter, it is needed to prepend this at the beginning of chk_report_conn_err() : if (!check->server) return; We need to make sure that check->server is properly tested everywhere. With a bit of luck this one was the only remnant. Thanks! Willy With the check above added, mail alerts seem to work properly here, or just as good as they used to anyhow. Once the patches and above addition get committed, that leaves the other 'low priority' issue of needing a short timeout to send the exact amount of 'expected' mails. EXPECT resp.http.mailsreceived (10) == "16" failed To be honest i only noticed it due to making the regtest, and double-checking what to expect.. When i validated mails on my actual environment it seems to work properly. (Though the server i took out to test has a health-check with a 60 second interval..) Anyhow its been like this for years afaik, i guess it wont matter much if stays like this a bit longer. Regards, PiBa-NL (Pieter)
Re: Lots of mail from email alert on 1.9.x
Hi Pieter, On Sat, Jan 12, 2019 at 01:00:33AM +0100, PiBa-NL wrote: > Thanks for this 'change in behavior' ;). Indeed the mailbomb is fixed, and > it seems the expected mails get generated and delivered, but a segfault also > happens on occasion. Not with the regtest as it was, but with a few minor > modifications (adding a unreachable mailserver, and giving it a little more > time seems to be the most reliable reproduction a.t.m.) it will crash > consistently after 11 seconds.. So i guess the patch needs a bit more > tweaking. > > Regards, > PiBa-NL (Pieter) > > Core was generated by `haproxy -d -f /tmp/vtc.37274.4b8a1a3a/h1/cfg'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00500955 in chk_report_conn_err (check=0x802616a10, > errno_bck=0, expired=1) at src/checks.c:689 > 689 dns_trigger_resolution(check->server->dns_requester); > (gdb) bt full > #0 0x00500955 in chk_report_conn_err (check=0x802616a10, > errno_bck=0, expired=1) at src/checks.c:689 Indeed, this function should not have any special effect in this case, it is needed to prepend this at the beginning of chk_report_conn_err() : if (!check->server) return; We need to make sure that check->server is properly tested everywhere. With a bit of luck this one was the only remnant. Thanks! Willy
Re: Lots of mail from email alert on 1.9.x
Hi Olivier,
Op 11-1-2019 om 19:17 schreef Olivier Houchard:
Ok so erm, I'd be lying if I claimed I enjoy working on the check code, or
that I understand it fully. However, after talking with Willy and Christopher,
I think I may have comed with an acceptable solution, and the attached patch
should fix it (at least by getting haproxy to segfault, but it shouldn't
mailbomb you anymore).
Pieter, I'd be very interested to know if it still work with your setup.
It's a different way of trying to fix what you tried ot fix with
1714b9f28694d750d446917672dd59c46e16afd7
I'd like to be sure I didn't break it for you again:)
Regards,
Olivier
(Slightly modified patches, I think there were a potential race condition
when running with multiple threads).
Olivier
Thanks for this 'change in behavior' ;). Indeed the mailbomb is fixed,
and it seems the expected mails get generated and delivered, but a
segfault also happens on occasion. Not with the regtest as it was, but
with a few minor modifications (adding a unreachable mailserver, and
giving it a little more time seems to be the most reliable reproduction
a.t.m.) it will crash consistently after 11 seconds.. So i guess the
patch needs a bit more tweaking.
Regards,
PiBa-NL (Pieter)
Core was generated by `haproxy -d -f /tmp/vtc.37274.4b8a1a3a/h1/cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00500955 in chk_report_conn_err (check=0x802616a10,
errno_bck=0, expired=1) at src/checks.c:689
689 dns_trigger_resolution(check->server->dns_requester);
(gdb) bt full
#0 0x00500955 in chk_report_conn_err (check=0x802616a10,
errno_bck=0, expired=1) at src/checks.c:689
cs = 0x8027de0c0
conn = 0x802683180
err_msg = 0x80266d0c0 " at step 1 of tcp-check (connect)"
chk = 0x80097b848
step = 1
comment = 0x0
#1 0x005065a5 in process_chk_conn (t=0x802656640,
context=0x802616a10, state=513) at src/checks.c:2261
check = 0x802616a10
proxy = 0x8026c3000
cs = 0x8027de0c0
conn = 0x802683180
rv = 0
ret = 0
expired = 1
#2 0x0050596e in process_chk (t=0x802656640,
context=0x802616a10, state=513) at src/checks.c:2330
check = 0x802616a10
#3 0x004fe0a2 in process_email_alert (t=0x802656640,
context=0x802616a10, state=513) at src/checks.c:3210
check = 0x802616a10
q = 0x802616a00
alert = 0x7fffe340
#4 0x005f2523 in process_runnable_tasks () at src/task.c:435
t = 0x802656640
state = 513
ctx = 0x802616a10
process = 0x4fdeb0
t = 0x8026566e0
max_processed = 200
#5 0x005163a2 in run_poll_loop () at src/haproxy.c:2619
next = 1062130135
exp = 1062129684
#6 0x00512ff8 in run_thread_poll_loop (data=0x8026310f0) at
src/haproxy.c:2684
start_lock = 0
ptif = 0x935d40
---Type to continue, or q to quit---
ptdf = 0x0
#7 0x0050f626 in main (argc=4, argv=0x7fffead8) at
src/haproxy.c:3313
tids = 0x8026310f0
threads = 0x8026310f8
i = 1
old_sig = {__bits = {0, 0, 0, 0}}
blocked_sig = {__bits = {4227856759, 4294967295, 4294967295,
4294967295}}
err = 0
retry = 200
limit = {rlim_cur = 4046, rlim_max = 4046}
errmsg =
"\000\352\377\377\377\177\000\000\000\353\377\377\377\177\000\000\330\352\377\377\377\177\000\000\004\000\000\000\000\000\000\00
0\b\250\037\315})5:`)\224\000\000\000\000\000\320\352\377\377\377\177\000\000\000\353\377\377\377\177\000\000\330\352\377\377\377\177\000\000\004
\000\000\000\000\000\00
reg-tests/mailers/k_healthcheckmail.vtc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/reg-tests/mailers/k_healthcheckmail.vtc
b/reg-tests/mailers/k_healthcheckmail.vtc
index d3af3589..820191c8 100644
--- a/reg-tests/mailers/k_healthcheckmail.vtc
+++ b/reg-tests/mailers/k_healthcheckmail.vtc
@@ -48,6 +48,7 @@ defaults
# timeout mail 20s
# timeout mail 200ms
mailer smtp1 ${h1_femail_addr}:${h1_femail_port}
+ mailer smtp2 ipv4@192.0.2.100:1025
} -start
@@ -62,7 +63,7 @@ client c1 -connect ${h1_luahttpservice_sock} {
delay 2
server s2 -repeat 5 -start
-delay 5
+delay 10
client c2 -connect ${h1_luahttpservice_sock} {
timeout 2
Re: Lots of mail from email alert on 1.9.x
On Fri, Jan 11, 2019 at 06:53:11PM +0100, Olivier Houchard wrote:
> Hi,
>
> On Fri, Jan 11, 2019 at 10:36:04AM +0100, Johan Hendriks wrote:
> > Thanks all.
> > No rush on my side as it is a test machine, at least we do know when a
> > backend server fails.
> > With all this mail the mail server are giving alarms too :D
> >
> > I disable the mail feature for now.
> >
> > Thanks again Pieter, Willy and Oliver for all your work.
> >
> >
> > Op 10-01-19 om 20:05 schreef PiBa-NL:
> > > Hi Johan, Olivier, Willy,
> > >
> > > Op 10-1-2019 om 17:00 schreef Johan Hendriks:
> > >> I just updated to 1.9.1 on my test system.
> > >>
> > >> We noticed that when a server fails we now get tons of mail, and with
> > >> tons we mean a lot.
> > >>
> > >> After a client backend server fails we usually get 1 mail on 1.8.x now
> > >> with 1.9.1 within 1 minute we have the following.
> > >>
> > >> mailq | grep -B2 l...@testdomain.nl | grep '^[A-F0-9]' | awk '{print
> > >> $1}' | sed 's/*//' | postsuper -d -
> > >> postsuper: Deleted: 19929 messages
> > >>
> > >> My setting from the backend part is as follows.
> > >>
> > >> email-alert mailers alert-mailers
> > >> email-alert from l...@testdomain.nl
> > >> email-alert to not...@testdomain.nl
> > >> server webserver09 11.22.33.44:80 check
> > >>
> > >> Has something changed in 1.9.x (it was on 1.9.0 also)
> > >>
> > >> regards
> > >> Johan Hendriks
> > >>
> > >>
> > > Its a 'known issue' see:
> > > https://www.mail-archive.com/haproxy@formilux.org/msg32290.html
> > > a 'regtest' is added in that mail thread also to aid developers in
> > > reproducing the issue and validating a possible fix.
> > >
> > > @Olivier, Willy, may i assume this mailbomb feature is 'planned' to
> > > get fixed in 1.9.2 ? (perhaps a bugtracker with a 'target version'
> > > would be nice ;) ?)
> > >
> > > Regards,
> > > PiBa-NL (Pieter)
> >
>
> Ok so erm, I'd be lying if I claimed I enjoy working on the check code, or
> that I understand it fully. However, after talking with Willy and Christopher,
> I think I may have comed with an acceptable solution, and the attached patch
> should fix it (at least by getting haproxy to segfault, but it shouldn't
> mailbomb you anymore).
> Pieter, I'd be very interested to know if it still work with your setup.
> It's a different way of trying to fix what you tried ot fix with
> 1714b9f28694d750d446917672dd59c46e16afd7
> I'd like to be sure I didn't break it for you again :)
>
> Regards,
>
> Olivier
(Slightly modified patches, I think there were a potential race condition
when running with multiple threads).
Olivier
>From 7e7b41cac480029c5fd93338dd86a875fee0b5a7 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Fri, 11 Jan 2019 18:17:17 +0100
Subject: [PATCH 1/2] MINOR: checks: Store the proxy in checks.
Instead of assuming we have a server, store the proxy directly in struct
check, and use it instead of s->server.
This should be a no-op for now, but will be useful later when we change
mail checks to avoid having a server.
This should be backported to 1.9.
---
include/types/checks.h | 1 +
src/checks.c | 32 +---
src/server.c | 1 +
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/include/types/checks.h b/include/types/checks.h
index 6346fe33..f89abcba 100644
--- a/include/types/checks.h
+++ b/include/types/checks.h
@@ -180,6 +180,7 @@ struct check {
int send_string_len;/* length of agent command
string */
char *send_string; /* optionally send a string
when connecting to the agent */
struct server *server; /* back-pointer to server */
+ struct proxy *proxy;/* proxy to be used */
char **argv;/* the arguments to use if
running a process-based check */
char **envp;/* the environment to use if
running a process-based check */
struct pid_list *curpid;/* entry in pid_list used for
current process-based test, or -1 if not in test */
diff --git a/src/checks.c b/src/checks.c
index 4baaf9fc..edb61b4f 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -2124,7 +2124,7 @@ static struct task *process_chk_proc(struct task *t, void
*context, unsigned sho
static struct task *process_chk_conn(struct task *t, void *context, unsigned
short state)
{
struct check *check = context;
- struct server *s = check->server;
+ struct proxy *proxy = check->proxy;
struct conn_stream *cs = check->cs;
struct connection *conn = cs_conn(cs);
int rv;
@@ -2142,7 +2142,7 @@ static struct task *process_chk_conn(struct task *t, void
*context, unsigned sho
* is disabled.
*/
if (((check->state & (CHK_ST_ENABLED | CHK_ST_PAUSED)) !=
CHK_ST_ENABLED) ||
- s->proxy->state == PR_STSTOPPED)
+
Re: Lots of mail from email alert on 1.9.x
Hi,
On Fri, Jan 11, 2019 at 10:36:04AM +0100, Johan Hendriks wrote:
> Thanks all.
> No rush on my side as it is a test machine, at least we do know when a
> backend server fails.
> With all this mail the mail server are giving alarms too :D
>
> I disable the mail feature for now.
>
> Thanks again Pieter, Willy and Oliver for all your work.
>
>
> Op 10-01-19 om 20:05 schreef PiBa-NL:
> > Hi Johan, Olivier, Willy,
> >
> > Op 10-1-2019 om 17:00 schreef Johan Hendriks:
> >> I just updated to 1.9.1 on my test system.
> >>
> >> We noticed that when a server fails we now get tons of mail, and with
> >> tons we mean a lot.
> >>
> >> After a client backend server fails we usually get 1 mail on 1.8.x now
> >> with 1.9.1 within 1 minute we have the following.
> >>
> >> mailq | grep -B2 l...@testdomain.nl | grep '^[A-F0-9]' | awk '{print
> >> $1}' | sed 's/*//' | postsuper -d -
> >> postsuper: Deleted: 19929 messages
> >>
> >> My setting from the backend part is as follows.
> >>
> >> email-alert mailers alert-mailers
> >> email-alert from l...@testdomain.nl
> >> email-alert to not...@testdomain.nl
> >> server webserver09 11.22.33.44:80 check
> >>
> >> Has something changed in 1.9.x (it was on 1.9.0 also)
> >>
> >> regards
> >> Johan Hendriks
> >>
> >>
> > Its a 'known issue' see:
> > https://www.mail-archive.com/haproxy@formilux.org/msg32290.html
> > a 'regtest' is added in that mail thread also to aid developers in
> > reproducing the issue and validating a possible fix.
> >
> > @Olivier, Willy, may i assume this mailbomb feature is 'planned' to
> > get fixed in 1.9.2 ? (perhaps a bugtracker with a 'target version'
> > would be nice ;) ?)
> >
> > Regards,
> > PiBa-NL (Pieter)
>
Ok so erm, I'd be lying if I claimed I enjoy working on the check code, or
that I understand it fully. However, after talking with Willy and Christopher,
I think I may have comed with an acceptable solution, and the attached patch
should fix it (at least by getting haproxy to segfault, but it shouldn't
mailbomb you anymore).
Pieter, I'd be very interested to know if it still work with your setup.
It's a different way of trying to fix what you tried ot fix with
1714b9f28694d750d446917672dd59c46e16afd7
I'd like to be sure I didn't break it for you again :)
Regards,
Olivier
>From 7e7b41cac480029c5fd93338dd86a875fee0b5a7 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Fri, 11 Jan 2019 18:17:17 +0100
Subject: [PATCH 1/2] MINOR: checks: Store the proxy in checks.
Instead of assuming we have a server, store the proxy directly in struct
check, and use it instead of s->server.
This should be a no-op for now, but will be useful later when we change
mail checks to avoid having a server.
This should be backported to 1.9.
---
include/types/checks.h | 1 +
src/checks.c | 32 +---
src/server.c | 1 +
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/include/types/checks.h b/include/types/checks.h
index 6346fe33..f89abcba 100644
--- a/include/types/checks.h
+++ b/include/types/checks.h
@@ -180,6 +180,7 @@ struct check {
int send_string_len;/* length of agent command
string */
char *send_string; /* optionally send a string
when connecting to the agent */
struct server *server; /* back-pointer to server */
+ struct proxy *proxy;/* proxy to be used */
char **argv;/* the arguments to use if
running a process-based check */
char **envp;/* the environment to use if
running a process-based check */
struct pid_list *curpid;/* entry in pid_list used for
current process-based test, or -1 if not in test */
diff --git a/src/checks.c b/src/checks.c
index 4baaf9fc..edb61b4f 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -2124,7 +2124,7 @@ static struct task *process_chk_proc(struct task *t, void
*context, unsigned sho
static struct task *process_chk_conn(struct task *t, void *context, unsigned
short state)
{
struct check *check = context;
- struct server *s = check->server;
+ struct proxy *proxy = check->proxy;
struct conn_stream *cs = check->cs;
struct connection *conn = cs_conn(cs);
int rv;
@@ -2142,7 +2142,7 @@ static struct task *process_chk_conn(struct task *t, void
*context, unsigned sho
* is disabled.
*/
if (((check->state & (CHK_ST_ENABLED | CHK_ST_PAUSED)) !=
CHK_ST_ENABLED) ||
- s->proxy->state == PR_STSTOPPED)
+ proxy->state == PR_STSTOPPED)
goto reschedule;
/* we'll initiate a new check */
@@ -2167,8 +2167,8 @@ static struct task *process_chk_conn(struct task *t, void
*context, unsigned sho
*/
t->expire = tick_add(now_ms,
Re: Lots of mail from email alert on 1.9.x
Thanks all.
No rush on my side as it is a test machine, at least we do know when a
backend server fails.
With all this mail the mail server are giving alarms too :D
I disable the mail feature for now.
Thanks again Pieter, Willy and Oliver for all your work.
Op 10-01-19 om 20:05 schreef PiBa-NL:
> Hi Johan, Olivier, Willy,
>
> Op 10-1-2019 om 17:00 schreef Johan Hendriks:
>> I just updated to 1.9.1 on my test system.
>>
>> We noticed that when a server fails we now get tons of mail, and with
>> tons we mean a lot.
>>
>> After a client backend server fails we usually get 1 mail on 1.8.x now
>> with 1.9.1 within 1 minute we have the following.
>>
>> mailq | grep -B2 l...@testdomain.nl | grep '^[A-F0-9]' | awk '{print
>> $1}' | sed 's/*//' | postsuper -d -
>> postsuper: Deleted: 19929 messages
>>
>> My setting from the backend part is as follows.
>>
>> email-alert mailers alert-mailers
>> email-alert from l...@testdomain.nl
>> email-alert to not...@testdomain.nl
>> server webserver09 11.22.33.44:80 check
>>
>> Has something changed in 1.9.x (it was on 1.9.0 also)
>>
>> regards
>> Johan Hendriks
>>
>>
> Its a 'known issue' see:
> https://www.mail-archive.com/haproxy@formilux.org/msg32290.html
> a 'regtest' is added in that mail thread also to aid developers in
> reproducing the issue and validating a possible fix.
>
> @Olivier, Willy, may i assume this mailbomb feature is 'planned' to
> get fixed in 1.9.2 ? (perhaps a bugtracker with a 'target version'
> would be nice ;) ?)
>
> Regards,
> PiBa-NL (Pieter)
Re: Lots of mail from email alert on 1.9.x
Hi Pieter,
On Thu, Jan 10, 2019 at 08:05:47PM +0100, PiBa-NL wrote:
> Hi Johan, Olivier, Willy,
>
> Op 10-1-2019 om 17:00 schreef Johan Hendriks:
> > I just updated to 1.9.1 on my test system.
> >
> > We noticed that when a server fails we now get tons of mail, and with
> > tons we mean a lot.
> >
> > After a client backend server fails we usually get 1 mail on 1.8.x now
> > with 1.9.1 within 1 minute we have the following.
> >
> > mailq | grep -B2 l...@testdomain.nl | grep '^[A-F0-9]' | awk '{print
> > $1}' | sed 's/*//' | postsuper -d -
> > postsuper: Deleted: 19929 messages
> >
> > My setting from the backend part is as follows.
> >
> > email-alert mailers alert-mailers
> > email-alert from l...@testdomain.nl
> > email-alert to not...@testdomain.nl
> > server webserver09 11.22.33.44:80 check
> >
> > Has something changed in 1.9.x (it was on 1.9.0 also)
> >
> > regards
> > Johan Hendriks
> >
> >
> Its a 'known issue' see:
> https://www.mail-archive.com/haproxy@formilux.org/msg32290.html
> a 'regtest' is added in that mail thread also to aid developers in
> reproducing the issue and validating a possible fix.
>
> @Olivier, Willy, may i assume this mailbomb feature is 'planned' to get
> fixed in 1.9.2 ? (perhaps a bugtracker with a 'target version' would be nice
> ;) ?)
Planned to be worked on, sure, but we need to figure how all this stuff
is supposed to work at all first. And I will definitely not want to keep
1.9.2 hostage of this. So the sooner it's figured the better, but that's
all I can say at this point :-(
Cheers,
Willy
Re: Lots of mail from email alert on 1.9.x
Hi Johan, Olivier, Willy,
Op 10-1-2019 om 17:00 schreef Johan Hendriks:
I just updated to 1.9.1 on my test system.
We noticed that when a server fails we now get tons of mail, and with
tons we mean a lot.
After a client backend server fails we usually get 1 mail on 1.8.x now
with 1.9.1 within 1 minute we have the following.
mailq | grep -B2 l...@testdomain.nl | grep '^[A-F0-9]' | awk '{print
$1}' | sed 's/*//' | postsuper -d -
postsuper: Deleted: 19929 messages
My setting from the backend part is as follows.
email-alert mailers alert-mailers
email-alert from l...@testdomain.nl
email-alert to not...@testdomain.nl
server webserver09 11.22.33.44:80 check
Has something changed in 1.9.x (it was on 1.9.0 also)
regards
Johan Hendriks
Its a 'known issue' see:
https://www.mail-archive.com/haproxy@formilux.org/msg32290.html
a 'regtest' is added in that mail thread also to aid developers in
reproducing the issue and validating a possible fix.
@Olivier, Willy, may i assume this mailbomb feature is 'planned' to get
fixed in 1.9.2 ? (perhaps a bugtracker with a 'target version' would be
nice ;) ?)
Regards,
PiBa-NL (Pieter)
