Release Date of HAProxy version 1.5
Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. I appreciate your response on that. Regards, Haroon
Re: Release Date of HAProxy version 1.5
Hi I asked the same question and was advised to at least start testing. I have done so and can say that we have not experienced any downtime due to haproxy. I use it in conjunction with corosync/pacemaker. I would probably advise the same. Start testing now. Kobus On 24/02/2014 09:29, Haroon Asher wrote: Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. I appreciate your response on that. Regards, Haroon -- Kobus Bensch Trustpay Global LTD email signature Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD DDI: 0207 871 3958 Tel: 0207 871 3890 Email: kobus.ben...@trustpayglobal.com mailto:kobus.ben...@trustpayglobal.com -- Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.com. The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message. inline: TrustPayGlobal_email_footer.png
Re: Release Date of HAProxy version 1.5
Le 24/02/2014 10:29, Haroon Asher a écrit : Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. hi, i actually use it in production without any issue since months. This is very basic usage but it works fine for us with no glitch for now. For the 1.5 we do not have big traffic web sites only moderate one where we use haproxy just to protect apache from basic attacks. regards, Ghislain.
Re: Just a simple thought on health checks after a soft reload of HAProxy....
Hi Malcolm, Hence the retry and redispatch options :) I know it's a dirty workaround. Baptiste On Sun, Feb 23, 2014 at 8:42 PM, Malcolm Turnbull malc...@loadbalancer.org wrote: Neil, Yes, peers are great for passing stick tables to the new HAProxy instance and any current connections bound to the old process will be fine. However any new connections will hit the new HAProxy process and if the backend server is down but haproxy hasn't health checked it yet then the user will hit a failed server. On 23 February 2014 10:38, Neil n...@iamafreeman.com wrote: Hello Regarding restarts, rather that cold starts, if you configure peers the state from before the restart should be kept. The new process haproxy creates is automatically a peer to the existing process and gets the state as was. Neil On 23 Feb 2014 03:46, Patrick Hemmer hapr...@stormcloud9.net wrote: From: Sok Ann Yap sok...@gmail.com Sent: 2014-02-21 05:11:48 E To: haproxy@formilux.org Subject: Re: Just a simple thought on health checks after a soft reload of HAProxy Patrick Hemmer haproxy@... writes: From: Willy Tarreau w at 1wt.eu Sent: 2014-01-25 05:45:11 E Till now that's exactly what's currently done. The servers are marked almost dead, so the first check gives the verdict. Initially we had all checks started immediately. But it caused a lot of issues at several places where there were a high number of backends or servers mapped to the same hardware, because the rush of connection really caused the servers to be flagged as down. So we started to spread the checks over the longest check period in a farm. Is there a way to enable this behavior? In my environment/configuration, it causes absolutely no issue that all the checks be fired off at the same time. As it is right now, when haproxy starts up, it takes it quite a while to discover which servers are down. -Patrick I faced the same problem in http://thread.gmane.org/ gmane.comp.web.haproxy/14644 After much contemplation, I decided to just patch away the initial spread check behavior: https://github.com/sayap/sayap-overlay/blob/master/net- proxy/haproxy/files/haproxy-immediate-first-check.diff I definitely think there should be an option to disable the behavior. We have an automated system which adds and removes servers from the config, and then bounces haproxy. Every time haproxy is bounced, we have a period where it can send traffic to a dead server. There's also a related bug on this. The bug is that when I have a config with inter 30s fastinter 1s and no httpchk enabled, when haproxy first starts up, it spreads the checks over the period defined as fastinter, but the stats output says UP 1/3 for the full 30 seconds. It also says L4OK in 30001ms, when I know it doesn't take the server 30 seconds to simply accept a connection. Yet you get different behavior when using httpchk. When I add option httpchk, it still spreads the checks over the 1s fastinter value, but the stats output goes full UP immediately after the check occurs, not UP 1/3. It also says L7OK/200 in 0ms, which is what I expect to see. -Patrick -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
Re: Just a simple thought on health checks after a soft reload of HAProxy....
Unfortunately retry doesn't work in our case as we run haproxy on 2 layers, frontend servers and backend servers (to distribute traffic among multiple processes on each server). So when an app on a server goes down, the haproxy on that server is still up and accepting connections, but the layer 7 http checks from the frontend haproxy are failing. But since the backend haproxy is still accepting connections, the retry option does not work. -Patrick *From: *Baptiste bed...@gmail.com *Sent: * 2014-02-24 07:18:00 E *To: *Malcolm Turnbull malc...@loadbalancer.org *CC: *Neil n...@iamafreeman.com, Patrick Hemmer hapr...@stormcloud9.net, HAProxy haproxy@formilux.org *Subject: *Re: Just a simple thought on health checks after a soft reload of HAProxy Hi Malcolm, Hence the retry and redispatch options :) I know it's a dirty workaround. Baptiste On Sun, Feb 23, 2014 at 8:42 PM, Malcolm Turnbull malc...@loadbalancer.org wrote: Neil, Yes, peers are great for passing stick tables to the new HAProxy instance and any current connections bound to the old process will be fine. However any new connections will hit the new HAProxy process and if the backend server is down but haproxy hasn't health checked it yet then the user will hit a failed server. On 23 February 2014 10:38, Neil n...@iamafreeman.com wrote: Hello Regarding restarts, rather that cold starts, if you configure peers the state from before the restart should be kept. The new process haproxy creates is automatically a peer to the existing process and gets the state as was. Neil On 23 Feb 2014 03:46, Patrick Hemmer hapr...@stormcloud9.net wrote: From: Sok Ann Yap sok...@gmail.com Sent: 2014-02-21 05:11:48 E To: haproxy@formilux.org Subject: Re: Just a simple thought on health checks after a soft reload of HAProxy Patrick Hemmer haproxy@... writes: From: Willy Tarreau w at 1wt.eu Sent: 2014-01-25 05:45:11 E Till now that's exactly what's currently done. The servers are marked almost dead, so the first check gives the verdict. Initially we had all checks started immediately. But it caused a lot of issues at several places where there were a high number of backends or servers mapped to the same hardware, because the rush of connection really caused the servers to be flagged as down. So we started to spread the checks over the longest check period in a farm. Is there a way to enable this behavior? In my environment/configuration, it causes absolutely no issue that all the checks be fired off at the same time. As it is right now, when haproxy starts up, it takes it quite a while to discover which servers are down. -Patrick I faced the same problem in http://thread.gmane.org/ gmane.comp.web.haproxy/14644 After much contemplation, I decided to just patch away the initial spread check behavior: https://github.com/sayap/sayap-overlay/blob/master/net- proxy/haproxy/files/haproxy-immediate-first-check.diff I definitely think there should be an option to disable the behavior. We have an automated system which adds and removes servers from the config, and then bounces haproxy. Every time haproxy is bounced, we have a period where it can send traffic to a dead server. There's also a related bug on this. The bug is that when I have a config with inter 30s fastinter 1s and no httpchk enabled, when haproxy first starts up, it spreads the checks over the period defined as fastinter, but the stats output says UP 1/3 for the full 30 seconds. It also says L4OK in 30001ms, when I know it doesn't take the server 30 seconds to simply accept a connection. Yet you get different behavior when using httpchk. When I add option httpchk, it still spreads the checks over the 1s fastinter value, but the stats output goes full UP immediately after the check occurs, not UP 1/3. It also says L7OK/200 in 0ms, which is what I expect to see. -Patrick -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
Re: Release Date of HAProxy version 1.5
I've been using 1.5.dev19 for a while now without issues. Again, like I said in the past, I'm aware dev21 comes with keep-alive which I haven't tested. regards On Mon, Feb 24, 2014 at 7:24 AM, Ghislain gad...@aqueos.com wrote: Le 24/02/2014 10:29, Haroon Asher a écrit : Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. hi, i actually use it in production without any issue since months. This is very basic usage but it works fine for us with no glitch for now. For the 1.5 we do not have big traffic web sites only moderate one where we use haproxy just to protect apache from basic attacks. regards, Ghislain. -- Gabriel Sosa Sometimes the questions are complicated and the answers are simple. -- Dr. Seuss
Re: Regression in 503 handling in v1.5-dev19-345-g6b726ad
On Mon, Feb 24, 2014 at 03:38:44PM +0100, Finn Arne Gangstad wrote: Thanks, verified both in the trivial test case and on a production server, now seems to work as before. cool, thanks for testing. Willy
Keeping statistics after a reload
Hi all, is there a way to reload a haproxy config without resetting the statistics shown on the stats page? I used haproxy -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) to make such a reload. But after that all statistics are reset. Best regards Andreas Mock
AW: Release Date of HAProxy version 1.5
Hi Kobus, I would be interested in your pacemaker agent config? Can you post your pacemaker snippet? What resource agent are you using? Thank you in advance. Regards Andreas Mock Von: Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] Gesendet: Montag, 24. Februar 2014 10:55 An: haproxy@formilux.org Betreff: Re: Release Date of HAProxy version 1.5 Hi I asked the same question and was advised to at least start testing. I have done so and can say that we have not experienced any downtime due to haproxy. I use it in conjunction with corosync/pacemaker. I would probably advise the same. Start testing now. Kobus On 24/02/2014 09:29, Haroon Asher wrote: Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. I appreciate your response on that. Regards, Haroon -- Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD DDI: 0207 871 3958 Tel: 0207 871 3890 Email: kobus.ben...@trustpayglobal.commailto:kobus.ben...@trustpayglobal.com [cid:image001.png@01CF317E.D5B939C0] Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.comhttp://www.trustpayglobal.com. The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message. inline: image001.png
Re: AW: Release Date of HAProxy version 1.5
Hi Andreas Sure. Here is my pacemaker config. I have tried to use the HAproxy resource, but for some reason it does not switch properly when one node fails. So for now, due to time constraints, I have written a script to check which noide is master and to start haproxy on that node and stop it on the slave. I will have another go at getting the HAproxy resource to work, unless of course there is someone on the list that is already doing it and is willing to share some info. node dc1ntgalb0101.domain.com node dc1ntgalb0102.domain.com primitive dc1ntgaip01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.110 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgblv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.119 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgilv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.125 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgrlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.122 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgxlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.116 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntiblv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.121 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntiilv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.127 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntirlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.124 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntixlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.118 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmblv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.120 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmilv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.126 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmrlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.123 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmxlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.117 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started colocation proxyservices inf: dc1ntgaip01 dc1ntgxlv01 dc1ntmxlv01 dc1ntixlv01 dc1ntgblv01 dc1ntmblv01 dc1ntiblv01 dc1ntgrlv01 dc1ntmrlv01 dc1ntirlv01 dc1ntgilv01 dc1ntmilv01 dc1ntiilv01 property $id=cib-bootstrap-options \ dc-version=1.1.10-14.el6_5.2-368c726 \ cluster-infrastructure=classic openais (with plugin) \ expected-quorum-votes=2 \ stonith-enabled=false \ no-quorum-policy=ignore rsc_defaults $id=rsc-options \ resource-stickiness=100 On 24/02/2014 15:38, Andreas Mock wrote: Kobus Bensch Trustpay Global LTD email signature Hi Kobus, I would be interested in your pacemaker agent config? Can you post your pacemaker snippet? What resource agent are you using? Thank you in advance. Regards Andreas Mock *Von:*Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] *Gesendet:* Montag, 24. Februar 2014 10:55 *An:* haproxy@formilux.org *Betreff:* Re: Release Date of HAProxy version 1.5 Hi I asked the same question and was advised to at least start testing. I have done so and can say that we have not experienced any downtime due to haproxy. I use it in conjunction with corosync/pacemaker. I would probably advise the same. Start testing now. Kobus On 24/02/2014 09:29, Haroon Asher wrote: Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. I appreciate your response on that. Regards, Haroon -- Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD DDI: 0207 871 3958 Tel: 0207 871 3890 Email: kobus.ben...@trustpayglobal.com mailto:kobus.ben...@trustpayglobal.com Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.com http://www.trustpayglobal.com. The information in this email and any
AW: AW: Release Date of HAProxy version 1.5
Hi Kobus, so, the most interesting part is missing... :-) I really hoped you will use a clonable resource agent running a haproxy instance on every node transmitting the current status via peer config, so that a switchover wouldn't loose state. In this scenario it would be interesting to see which IP resource is used as haproxy would try to bind to nonexisting IP. Probably a ClusterIP resource. Thank you anyway. Best regards Andreas Mock Von: Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] Gesendet: Montag, 24. Februar 2014 16:53 An: Andreas Mock; haproxy@formilux.org Betreff: Re: AW: Release Date of HAProxy version 1.5 Hi Andreas Sure. Here is my pacemaker config. I have tried to use the HAproxy resource, but for some reason it does not switch properly when one node fails. So for now, due to time constraints, I have written a script to check which noide is master and to start haproxy on that node and stop it on the slave. I will have another go at getting the HAproxy resource to work, unless of course there is someone on the list that is already doing it and is willing to share some info. node dc1ntgalb0101.domain.com node dc1ntgalb0102.domain.com primitive dc1ntgaip01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.110 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgblv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.119 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgilv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.125 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgrlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.122 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntgxlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.116 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntiblv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.121 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntiilv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.127 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntirlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.124 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntixlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.118 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmblv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.120 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmilv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.126 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmrlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.123 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started primitive dc1ntmxlv01 ocf:heartbeat:IPaddr2 \ params ip=10.11.115.117 cidr_netmask=24 \ op monitor interval=30s \ meta target-role=Started colocation proxyservices inf: dc1ntgaip01 dc1ntgxlv01 dc1ntmxlv01 dc1ntixlv01 dc1ntgblv01 dc1ntmblv01 dc1ntiblv01 dc1ntgrlv01 dc1ntmrlv01 dc1ntirlv01 dc1ntgilv01 dc1ntmilv01 dc1ntiilv01 property $id=cib-bootstrap-options \ dc-version=1.1.10-14.el6_5.2-368c726 \ cluster-infrastructure=classic openais (with plugin) \ expected-quorum-votes=2 \ stonith-enabled=false \ no-quorum-policy=ignore rsc_defaults $id=rsc-options \ resource-stickiness=100 On 24/02/2014 15:38, Andreas Mock wrote: Hi Kobus, I would be interested in your pacemaker agent config? Can you post your pacemaker snippet? What resource agent are you using? Thank you in advance. Regards Andreas Mock Von: Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] Gesendet: Montag, 24. Februar 2014 10:55 An: haproxy@formilux.orgmailto:haproxy@formilux.org Betreff: Re: Release Date of HAProxy version 1.5 Hi I asked the same question and was advised to at least start testing. I have done so and can say that we have not experienced any downtime due to haproxy. I use it in conjunction with corosync/pacemaker. I would probably advise the same. Start testing now. Kobus On 24/02/2014 09:29, Haroon Asher wrote: Hello, We are using ha-proxy from past 3 years in our production environment. Now we are looking to use SSL Certificate on our site for which we will require haproxy version 1.5. Can you please let us know then when its release is planned or by when it will be stable enough to be used in production. I appreciate your response on that. Regards, Haroon -- Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford |
consistent server status between config reloads
Hi, I'm running some scripts that can disable a server for maintainance/application deployments. However a config reload enables the server again, and we have frequent changes to our haproxy config. Would it be possible to leave disabled servers in that state between reloads? Maybe with an additional config option like disable_permanent or the like? Any opinions on this? Best regards, Craig
Premier sur Google en 2014
Pour vous, être présent sur Google cest trouver de nouveaux clients. Mais combien coûte un bon référencement ? http://www.e-visibilite.com/referencement3.php
Goodbye from our Newsletter
Goodbye from our Newsletter, sorry to see you go. You have been unsubscribed from our newsletters. This is the last email you will receive from us. Our newsletter system, phpList, will refuse to send you any further messages, without manual intervention by our administrator. If there is an error in this information, you can re-subscribe: please go to http://tuinforme.com.ar/lists/?p=subscribe and follow the steps. Thank you
inspecting incoming tcp content
Hi, I wanted to inspect incoming tcp request. I wanted to something like below payload(0, 100) match with string like 49=ABC. Thanks, Anup
Re: http responses randomly getting RSTs
Finally came back here :) Lukas Tribus said the following on 02/20/2014 07:16 PM: [CUT] Try removing timeout client as well (never ever do this in production). You will see a startup warning, ignore it and test if you still can reproduce it. Without timeout http-request and timeout client you probably don't see this issue. I tried removing timeout client - and it did complain loudly about it when restarting, but I still get 408's.. (you can also verify yourself.. it shows up pretty much consistently, if I press enter on the url - and then press f5 after it has loaded. I'll run the script to test timejumps in a second :) -- Regards, Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 Those who do not understand Unix are condemned to reinvent it, poorly. --Henry Spencer
Re: http responses randomly getting RSTs
Willy Tarreau said the following on 02/20/2014 08:44 PM: [CUT] Or you can also use this old script I used many years ago to detect such issues : #!/bin/bash old=$(date +%s); while : ; do new=$(date +%s); if [ $new -lt $old ]; then echo Time jumps backwards : $old = $new elif [ $new -gt $((old+1)) ]; then echo Time jumps forwards : $old = $new fi old=$new done I had this running for a few minutes - while I was able to reproduce the 408 issue.. and it echo'ed nothing. I do monitor time and normally catch timejumps (I didn't even have to have tinker panic 0 set in ntpd.conf). [CUT] I just checked, and the two only situations where we may report a 408 are - when detecting a timeout waiting for a request ; - when detecting a timeout waiting for a body in balance url_param check-post But only the former will return cR. So there's no risk of inheritating this from somewhere else. The condition to enter this block is the following (proto_http.c:2486) : if (req-flags CF_READ_TIMEOUT || tick_is_expired(req-analyse_exp, now_ms)) So I'm seeing two possibilities : - the CF_READ_TIMEOUT flag was present on the channel - the http-request delay was really expired. Since the logs showed that the delay was very short, either it's the first case, or we're facing a case there analyse_exp is not properly set. This expiration is set from timeout http-request or from timeout http-keep-alive when processing the second and next requests. So here I don't think it can be the issue. Thus in my opinion, the only remaining possibility is that the CF_READ_TIMEOUT flag is set. It is normally set if the read timeout is reached. So here it will be timeout client. But that doesn't seem to make much sense, especially if you manage to reproduce it easily. last time it took me ~20 reloads, in a new firefox, of the page to reproduce it.. but on IE (on a buddys machine) it reproduces more easily. One thing I'm noticing is that this flag is not cleared between two consecutive requests over the same connection. So we could imagine a scenario where a read timeout is detected on the first request, but an event arrives just in time, at the exact same moment, resulting in the data still being processed while the flag is set. The request completes and reinitializes to handle the next request over the connection, but the flag is not cleared. Thus the second request would be the victim of this inherited timeout. It seems a bit far-fetched, but it could explain what you're seeing. Could you please add the following patch to proto_http.c (1.5.22) ? It will log in debug level a few flags and timers to try to better find what is happeneing when this happens. You'll need that your syslog deamon logs debug level entries, maybe they're stored in a differen file (eg: /var/log/debug). Otherwise you can change the level LOG_DEBUG for something else such as LOG_INFO. Warning, I copy pasted both the patches below, so you'll have to copy the lines or they won't apply due to mangled spaces. I'll apply the patch and build a new rpm.. will return back later today. Thank you very much for your assistance. -- Regards, Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 Those who do not understand Unix are condemned to reinvent it, poorly. --Henry Spencer
