Re: v1.9.6 socket unresponsive with high cpu usage
On Sun, May 05, 2019 at 07:07:21AM +0200, Willy Tarreau wrote: > Thus I conclude that it crashed, and that all other threads just met at > the same lock while the core was being dumped in this one. Or maybe the tree got corrupted and __eb_insert_dup() entered an endless loop. If that's the case (I mean if it froze and didn't crash), I may have something to make this safer soon. I more or less managed to create a watchdog timer to detect lockups and abort the whole process with a trace when this happens. This will avoid keeping a faulty process in prod and may even allow a quicker restart. I don't intend to backport it to 1.9 though but depending on how effective and helpful it is, I could change my mind. In all cases I don't want to use such solutions to hide the dust under the carpet but instead to take detailed traces without requiring human intervention when this happens. Willy
stable-bot: NOTICE: 14 bug fixes in queue for next release
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.9.7 was issued on 2019/04/25. There are currently 14 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2019/04/30 - 9 MEDIUM, first one merged on 2019/04/29 - 4 MINOR, first one merged on 2019/04/29 Thus the computed ideal release date for 1.9.8 would be 2019/05/14, which is in two weeks or less. The current list of patches in the queue is: - MAJOR : map/acl: real fix segfault during show map/acl on CLI - MEDIUM : channels: Don't forget to reset output in channel_erase(). - MEDIUM : pattern: fix memory leak in regex pattern functions - MEDIUM : servers: fix typo "src" instead of "srv" - MEDIUM : listener: Fix how unlimited number of consecutive accepts is handled - MEDIUM : port_range: Make the ring buffer lock-free. - MEDIUM : mux-h2: properly deal with too large headers frames - MEDIUM : spoe: arg len encoded in previous frag frame but len changed - MEDIUM : connections: Make sure we remove CO_FL_SESS_IDLE on disown. - MEDIUM : contrib/modsecurity: If host header is NULL, don't try to strdup it - MINOR : haproxy: fix rule->file memory leak - MINOR : http: Call stream_inc_be_http_req_ctr() only one time per request - MINOR : checks: free memory allocated for tasklets - MINOR : log: properly free memory on logformat parse error and deinit() --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
stable-bot: NOTICE: 6 bug fixes in queue for next release
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.8.20 was issued on 2019/04/25. There are currently 6 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2019/04/30 - 4 MEDIUM, first one merged on 2019/04/29 - 1 MINOR, first one merged on 2019/04/29 Thus the computed ideal release date for 1.8.21 would be 2019/05/14, which is in two weeks or less. The current list of patches in the queue is: - MAJOR : map/acl: real fix segfault during show map/acl on CLI - MEDIUM : contrib/modsecurity: If host header is NULL, don't try to strdup it - MEDIUM : port_range: Make the ring buffer lock-free. - MEDIUM : listener: Fix how unlimited number of consecutive accepts is handled - MEDIUM : spoe: arg len encoded in previous frag frame but len changed - MINOR : http: Call stream_inc_be_http_req_ctr() only one time per request --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: [ANNOUNCE] haproxy-1.8.20
On Sat, May 4, 2019 at 1:58 PM Vincent Bernat wrote: > The more changes, the less likely the release team will accept the > change. Assuming we can only make one proposition (which is not true), > what would you (as upstream) try? 1.8.19, one bug, all major bugs, even > more bugs, or 1.8.20? Not being able to push 1.8.20 is a bit depressing as it will make potential bug reports a bit hard for developers to follow. But anyway, it will push more users to use your external repository and avoid the official one. -- William
Re: [ANNOUNCE] haproxy-1.8.20
Vincent, Am 04.05.19 um 13:57 schrieb Vincent Bernat: > The more changes, the less likely the release team will accept the > change. Assuming we can only make one proposition (which is not true), > what would you (as upstream) try? 1.8.19, one bug, all major bugs, even > more bugs, or 1.8.20? > While I'm not upstream I am a happy user of both HAProxy and Debian. I believe that this MEDIUM patch should be proposed as well. I believe the OpenSSL version included in Buster supports TLS 1.3. BUG/MEDIUM: ssl: ability to set TLS 1.3 ciphers using ssl-default-server-ciphersuites http://git.haproxy.org/?p=haproxy-1.8.git;a=commitdiff;h=a2919ca Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-1.8.20
❦ 29 avril 2019 11:04 +02, Christopher Faulet : > HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits > after version 1.8.19. Hey! Debian Buster will soon be released (nobody knows exactly when, but we are in full freeze since 2 months). It currently contains HAProxy 1.8.19. I don't think it would be possible to push 1.8.20 as is. We can either keep 1.8.19 as is or select a few critical patches to apply on it. For example, we could take the MAJOR patches: BUG/MAJOR: checks: segfault during tcpcheck_main BUG/MAJOR: http_fetch: Get the channel depending on the keyword used BUG/MAJOR: listener: Make sure the listener exist before using it. BUG/MAJOR: spoe: Fix initialization of thread-dependent fields BUG/MAJOR: stats: Fix how huge POST data are read from the channel And maybe: BUG/MEDIUM: listener: make sure the listener never accepts too many conns The more changes, the less likely the release team will accept the change. Assuming we can only make one proposition (which is not true), what would you (as upstream) try? 1.8.19, one bug, all major bugs, even more bugs, or 1.8.20? -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger)
