Haproxy 1.8.25 segfault
Hi guys, We are getting segfaults with haproxy 1.8.25 and thought I would ask if this rings any bell: segfault at 5609a853 ip 7f1b93928c10 sp 7ffd5e731fd8 error 4 in libc-2.19.so[7f1b9388e000+1be000] It is running on Ubuntu-14.04.2 (kernel 4.4.0-144-generic) and is happening only on this particular one out of many dozens we have on Ubuntu-14.04 and 16.04 I have attached strace so more details upon the next crash. Thanks, Igor
Re: Time applied on DNS resolution with valid response
El 2020-05-23 15:48, Baptiste escribió: On Thu, May 21, 2020 at 11:47 AM Ricardo Fraile wrote: Hello, I'm fancing an extrange behaviour with DNS resolution and timeout/hold times. As testing enviroment, I use Haproxy 1.8.25 and this sample conf: global master-worker log /dev/log local5 info pidfile /var/run/haproxy.pid nbproc 1 resolvers dns nameserver dns1 1.1.1.1:53 [1] resolve_retries 3 timeout resolve 5s timeout retry10s hold other 10s hold valid 60s hold obsolete10s hold refused 10s hold nx 10s hold timeout 10s listen proxy-tcp mode tcp bind *:80 default-server check resolvers dns init-addr none resolve-prefer ipv4 server host1 host1:80 On the DNS server, the entry for host1 is valid as noted here: # dig host1 @1.1.1.1 [2] ;; ANSWER SECTION: host1. 300 IN A 7.7.7.7 But getting the network traffic from the DNS server I can see the following: 11:29:31.064136 IP [bal_ip].49967 > dns1: 121+ [1au] A? host1. (62) 11:29:36.065749 IP [bal_ip].49967 > dns1: 14393+ [1au] A? host1. (62) 11:29:41.067816 IP [bal_ip].49967 > dns1: 35337+ [1au] A? host1. (62) Each 5 seconds, as defined in "timeout resolve", it receives a query. But as it is valid, why Haproxy doesn't hold it with the time defined on "hold valid", 60 seconds? Thanks, Hi Ricardo Hold valid means that we keep this response for said period if the server becomes unresponsive or returns NX. HAProxy carry on performing queries at timeout.resolve period to ensure a faster convergence in case the response is updated. Baptiste Links: -- [1] http://1.1.1.1:53 [2] http://1.1.1.1 Thanks Baptiste, I haven't understood clearly the concepts with the documentation. Your comment fits with the behaviour that I see.
Re: Time applied on DNS resolution with valid response
On Thu, May 21, 2020 at 11:47 AM Ricardo Fraile wrote: > Hello, > > > I'm fancing an extrange behaviour with DNS resolution and timeout/hold > times. As testing enviroment, I use Haproxy 1.8.25 and this sample conf: > > global > master-worker > log /dev/log local5 info > pidfile /var/run/haproxy.pid > nbproc 1 > > resolvers dns > nameserver dns1 1.1.1.1:53 > > resolve_retries 3 > timeout resolve 5s > timeout retry10s > hold other 10s > hold valid 60s > hold obsolete10s > hold refused 10s > hold nx 10s > hold timeout 10s > > listen proxy-tcp > mode tcp > bind *:80 > default-server check resolvers dns init-addr none resolve-prefer > ipv4 > > server host1 host1:80 > > > > On the DNS server, the entry for host1 is valid as noted here: > > # dig host1 @1.1.1.1 > > ;; ANSWER SECTION: > host1. 300 IN A 7.7.7.7 > > > > But getting the network traffic from the DNS server I can see the > following: > > 11:29:31.064136 IP [bal_ip].49967 > dns1: 121+ [1au] A? host1. (62) > 11:29:36.065749 IP [bal_ip].49967 > dns1: 14393+ [1au] A? host1. (62) > 11:29:41.067816 IP [bal_ip].49967 > dns1: 35337+ [1au] A? host1. (62) > > Each 5 seconds, as defined in "timeout resolve", it receives a query. > But as it is valid, why Haproxy doesn't hold it with the time defined on > "hold valid", 60 seconds? > > > > Thanks, > > Hi Ricardo Hold valid means that we keep this response for said period if the server becomes unresponsive or returns NX. HAProxy carry on performing queries at timeout.resolve period to ensure a faster convergence in case the response is updated. Baptiste
Survey on Change Management
This email newsletter was sent to you in graphical HTML format. If you're seeing this version, your email program prefers plain text emails. You can read the original version online: https://ymlptr9.net/zxMlt3 Greetings Many organizations fail to respond to external and internal environment which in turn affect the well-being of the organization and may cause total shutdown and loss of business such as Nokia case. Other organizations are considering the Marketing Mix along with the change best practices to insure continued prosperity and revenues.The study will also conclude the best leadership style that should be associated with a change. This research is done to investigates the best practices of organizational change and the best leadership theory that could be used to implement change. It aims at helping organizations in implementing a successful change, as well as the marketing and leadership strategies of change adopted to insure successful implantation of the change. This study seeks to identify the most recurrent factors that drives organizational change, and to illustrate methodologies for an effective change. We kindly ask you to complete this quick 12 Questons Suervy in this regard. https://www.smartsurvey.co.uk/s/ChangeManagementleadershipstyle/ Many Thanks _ Unsubscribe / Change Profile: https://ymlptr9.net/ugwhmwyqgsguqhjummgessygguujwq Powered by YourMailingListProvider
[PATCH] cleanup coverity findging (make it silent)
Hello, let us clean up non important finding by wrapping it with DISGUISE(..) Cheers, Ilya Shipitcin From 7060a886a76452245ec466f6f7aaf28d504c9c3f Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Sat, 23 May 2020 15:35:36 +0500 Subject: [PATCH] CLEANUP: src/checks.c: ignore return value using DISGUISE(..) we do not want to check status of extchk_setenv, but static analyzsers like Coverity are not happy about it. Let calm coverity down. --- src/checks.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/checks.c b/src/checks.c index 01a27f87e..ea99145bd 100644 --- a/src/checks.c +++ b/src/checks.c @@ -3208,15 +3208,15 @@ static int connect_proc_chk(struct task *t) environ = check->envp; /* Update some environment variables and command args: curconn, server addr and server port */ - extchk_setenv(check, EXTCHK_HAPROXY_SERVER_CURCONN, ultoa_r(s->cur_sess, buf, sizeof(buf))); + DISGUISE(extchk_setenv(check, EXTCHK_HAPROXY_SERVER_CURCONN, ultoa_r(s->cur_sess, buf, sizeof(buf; addr_to_str(>addr, check->argv[3], EXTCHK_SIZE_ADDR); - extchk_setenv(check, EXTCHK_HAPROXY_SERVER_ADDR, check->argv[3]); + DISGUISE(extchk_setenv(check, EXTCHK_HAPROXY_SERVER_ADDR, check->argv[3])); *check->argv[4] = 0; if (s->addr.ss_family == AF_INET || s->addr.ss_family == AF_INET6) snprintf(check->argv[4], EXTCHK_SIZE_UINT, "%u", s->svc_port); - extchk_setenv(check, EXTCHK_HAPROXY_SERVER_PORT, check->argv[4]); + DISGUISE(extchk_setenv(check, EXTCHK_HAPROXY_SERVER_PORT, check->argv[4])); haproxy_unblock_signals(); execvp(px->check_command, check->argv); -- 2.26.2
