Re: [PATCH] BUG/MINOR: init: enforce strict-limits when using master-worker
Hi Jerome,
On Tue, Jan 12, 2021 at 08:36:57PM +0100, Jerome Magnin wrote:
> From ca260ac46cd441ed4108cdef7b304b6c0baec68c Mon Sep 17 00:00:00 2001
> From: Jerome Magnin
> Date: Tue, 12 Jan 2021 20:19:38 +0100
> Subject: [PATCH] BUG/MINOR: init: enforce strict-limits when using
> master-worker
>
> The strict-limits global option was introduced with commit 0fec3ab7b
> ("MINOR: init: always fail when setrlimit fails"). When used in
> conjuction with master-worker, haproxy will not fail when a setrlimit
> fails. This happens because we only exit() if master-worker isn't used.
>
> This patch removes all tests for master-worker mode for all cases covered
> by strict-limits scope.
>
> This should be backported from 2.1 onward.
> This should fix issue #1042.
just for the context we discussed in the issue:
this feature was originially implemented in a reload scenario where it
made the reload fail, without leaving the master worker.
I completely overlooked the start and I agree this patch is more aligned
with what the documentation is stating.
Could be nice to have this context in the commit message.
Outside of that I'm ok with the patch itself.
Reviewed by William Dauchy
--
William
Re: VTest broken on macOS
I did have a quick look today. I did not see any change related to failure. I'd say it is compiler change on osx side. we can try to run osx vtest on 02a9bc16d78e70d1d415b40d5349b9f3e56df05b On Wed, Jan 13, 2021, 12:06 AM Tim Düsterhus wrote: > Hi List, > Ilya, > > as a heads up: It appears that recent VTest changes broke support for > macOS. I filed an issue upstream: https://github.com/vtest/VTest/issues/26 > > Best regards > Tim Düsterhus >
Re: [PR] proto_tcp.c: fix printing of muliple setsockopt errors
Hello, okay, the link to the MR patch landed on the list, so I assume I don't need to attache it here again. Confusing, that the issues are tracked there... Cheers Björn On 12.01.21 20:22, PR Bot wrote: > Dear list! > > Author: Björn Jacke > Number of patches: 1 > > This is an automated relay of the Github pull request: >proto_tcp.c: fix printing of muliple setsockopt errors > > Patch title(s): >proto_tcp.c: fix printing of muliple setsockopt errors > > Link: >https://github.com/haproxy/haproxy/pull/1049 > > Edit locally: >wget https://github.com/haproxy/haproxy/pull/1049.patch && vi 1049.patch > > Apply locally: >curl https://github.com/haproxy/haproxy/pull/1049.patch | git am - > > Description: >Attached patch is an attempt to fix the output of multiple >setsockopt() warnings. Currently only the latest warning is printed >because msg is overwritten with each new failed setsockopt() call. >Signed-off-by: Bjoern Jacke > >There is at >least one thing left, which should be fixed somehow: if many >setsockopt() calls fail, then errlen exceeds and the warning message >is truncated, I've seen this happend actually. This is a TODO for >someone, who knows the code better :-) > > Instructions: >This github pull request will be closed automatically; patch should be >reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is >invited to comment, even the patch's author. Please keep the author and >list CCed in replies. Please note that in absence of any response this >pull request will be lost. >
[PATCH] BUG/MINOR: init: enforce strict-limits when using master-worker
Hi William, list,
This is a patch for issue 1042.
I removed all tests for master-worker mode for everything related to
strict-limits.
regards,
--
Jérôme
>From ca260ac46cd441ed4108cdef7b304b6c0baec68c Mon Sep 17 00:00:00 2001
From: Jerome Magnin
Date: Tue, 12 Jan 2021 20:19:38 +0100
Subject: [PATCH] BUG/MINOR: init: enforce strict-limits when using
master-worker
The strict-limits global option was introduced with commit 0fec3ab7b
("MINOR: init: always fail when setrlimit fails"). When used in
conjuction with master-worker, haproxy will not fail when a setrlimit
fails. This happens because we only exit() if master-worker isn't used.
This patch removes all tests for master-worker mode for all cases covered
by strict-limits scope.
This should be backported from 2.1 onward.
This should fix issue #1042.
---
src/haproxy.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/src/haproxy.c b/src/haproxy.c
index fcc4f6c70..7612e4c45 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -3111,8 +3111,7 @@ int main(int argc, char **argv)
if (global.tune.options & GTUNE_STRICT_LIMITS) {
ha_alert("[%s.main()] Cannot raise FD limit to
%d, limit is %d.\n",
argv[0], global.rlimit_nofile,
(int)limit.rlim_cur);
- if (!(global.mode & MODE_MWORKER))
- exit(1);
+ exit(1);
}
else {
/* try to set it to the max possible at least */
@@ -3135,8 +3134,7 @@ int main(int argc, char **argv)
if (global.tune.options & GTUNE_STRICT_LIMITS) {
ha_alert("[%s.main()] Cannot fix MEM limit to
%d megs.\n",
argv[0], global.rlimit_memmax);
- if (!(global.mode & MODE_MWORKER))
- exit(1);
+ exit(1);
}
else
ha_warning("[%s.main()] Cannot fix MEM limit to
%d megs.\n",
@@ -3147,8 +3145,7 @@ int main(int argc, char **argv)
if (global.tune.options & GTUNE_STRICT_LIMITS) {
ha_alert("[%s.main()] Cannot fix MEM limit to
%d megs.\n",
argv[0], global.rlimit_memmax);
- if (!(global.mode & MODE_MWORKER))
- exit(1);
+ exit(1);
}
else
ha_warning("[%s.main()] Cannot fix MEM limit to
%d megs.\n",
@@ -3320,8 +3317,7 @@ int main(int argc, char **argv)
"Please raise 'ulimit-n' to %d or more to
avoid any trouble.\n",
argv[0], (int)limit.rlim_cur, global.maxconn,
global.maxsock,
global.maxsock);
- if (!(global.mode & MODE_MWORKER))
- exit(1);
+ exit(1);
}
else
ha_alert("[%s.main()] FD limit (%d) too low for
maxconn=%d/maxsock=%d. "
@@ -3608,8 +3604,7 @@ int main(int argc, char **argv)
if (global.tune.options & GTUNE_STRICT_LIMITS) {
ha_alert("[%s.main()] Failed to set the raise
the maximum "
"file size.\n", argv[0]);
- if (!(global.mode & MODE_MWORKER))
- exit(1);
+ exit(1);
}
else
ha_warning("[%s.main()] Failed to set the raise
the maximum "
@@ -3622,8 +3617,7 @@ int main(int argc, char **argv)
if (global.tune.options & GTUNE_STRICT_LIMITS) {
ha_alert("[%s.main()] Failed to set the raise
the core "
"dump size.\n", argv[0]);
- if (!(global.mode & MODE_MWORKER))
- exit(1);
+ exit(1);
}
else
ha_warning("[%s.main()] Failed to set the raise
the core "
--
2.30.0
[PR] proto_tcp.c: fix printing of muliple setsockopt errors
Dear list! Author: Björn Jacke Number of patches: 1 This is an automated relay of the Github pull request: proto_tcp.c: fix printing of muliple setsockopt errors Patch title(s): proto_tcp.c: fix printing of muliple setsockopt errors Link: https://github.com/haproxy/haproxy/pull/1049 Edit locally: wget https://github.com/haproxy/haproxy/pull/1049.patch && vi 1049.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/1049.patch | git am - Description: Attached patch is an attempt to fix the output of multiple setsockopt() warnings. Currently only the latest warning is printed because msg is overwritten with each new failed setsockopt() call. Signed-off-by: Bjoern Jacke There is at least one thing left, which should be fixed somehow: if many setsockopt() calls fail, then errlen exceeds and the warning message is truncated, I've seen this happend actually. This is a TODO for someone, who knows the code better :-) Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
VTest broken on macOS
Hi List, Ilya, as a heads up: It appears that recent VTest changes broke support for macOS. I filed an issue upstream: https://github.com/vtest/VTest/issues/26 Best regards Tim Düsterhus
Re: [*EXT*] Re: coredump since 2.2.7 upgrade
Thanks Christopher, that was it.
2.2.7 with 8461b9 reverted is stable for me.
--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager
- Mail original -
De: "Christopher Faulet"
À: "Ionel GARDAIS" , "haproxy"
Envoyé: Mardi 12 Janvier 2021 16:57:47
Objet: [*EXT*] Re: coredump since 2.2.7 upgrade
Le 12/01/2021 à 16:28, Ionel GARDAIS a écrit :
> Hi,
>
> I'm getting continuous core dump since the upgrade to 2.2.7 on debian 9.
> Where can I send them ?
>
Hi,
If you are using the DNS, there is a bug introduced by a recent change, leading
to a segfault. We reverted the commit but it is not backported yet. In the mean
time, in the 2.2, the commit 8461b9ea78 ("BUG/MINOR: dns: SRV records ignores
duplicated AR records") must be reverted. The commit fixed the issue #971. A
new
fix is under evaluation.
The same bug exists in the 2.3.3. The commit 45b6d2d47 must be reverted.
--
Christopher Faulet
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Crash when using wlc in multithreaded mode with agent checks (1.8.26).
Mark Brookes wrote: > Sorry to drag up an old thread. But do we have an eta for a new > release of version 1.8 that contains the fix? I noticed that the 2.x > versions have been updated, and wanted to make sure that 1.8 has not > been left out by mistake. I have just updated the backports for haproxy 1.8, I will try to make a release with your fix soon. -- Amaury Denoyelle
Re: coredump since 2.2.7 upgrade
Le 12/01/2021 à 16:28, Ionel GARDAIS a écrit :
Hi,
I'm getting continuous core dump since the upgrade to 2.2.7 on debian 9.
Where can I send them ?
Hi,
If you are using the DNS, there is a bug introduced by a recent change, leading
to a segfault. We reverted the commit but it is not backported yet. In the mean
time, in the 2.2, the commit 8461b9ea78 ("BUG/MINOR: dns: SRV records ignores
duplicated AR records") must be reverted. The commit fixed the issue #971. A new
fix is under evaluation.
The same bug exists in the 2.3.3. The commit 45b6d2d47 must be reverted.
--
Christopher Faulet
coredump since 2.2.7 upgrade
Hi, I'm getting continuous core dump since the upgrade to 2.2.7 on debian 9. Where can I send them ? Jan 12 16:16:12 x haproxy[5204]: *** Error in `/usr/sbin/haproxy': corrupted double-linked list: 0x7f346802a550 *** Jan 12 16:16:12 x haproxy[5204]: === Backtrace: = Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f34839c5bfb] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f34839cbfc6] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(+0x7964c)[0x7f34839ce64c] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f34839cff64] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(CRYPTO_zalloc+0xe)[0x7f348455bf5e] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_DigestInit_ex+0x1b1)[0x7f348453ce21] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(PKCS1_MGF1+0xb4)[0x7f348458c254] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(RSA_padding_add_PKCS1_PSS_mgf1+0x213)[0x7f34845912c3] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x1be683)[0x7f3484590683] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_DigestSignFinal+0x180)[0x7f34845509e0] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x59bfe)[0x7f3484914bfe] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x4c74b)[0x7f348490774b] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_do_handshake+0x54)[0x7f34848f3d74] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(+0x51c9b)[0x55ce168d8c9b] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(run_tasks_from_lists+0x33d)[0x55ce16a4629d] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(process_runnable_tasks+0x3ac)[0x55ce16a46d4c] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(run_poll_loop+0xaa)[0x55ce169fcd2a] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(+0x176129)[0x55ce169fd129] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7f3484b514a4] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f3483a3dd0f] Jan 12 16:16:12 x haproxy[5204]: === Memory map: Jan 12 16:16:13 x haproxy[5204]: [ALERT] 011/161613 (5204) : Current worker #1 (5206) exited with code 134 (Aborted) Jan 12 16:16:13 x haproxy[5204]: [ALERT] 011/161613 (5204) : exit-on-failure: killing every processes with SIGTERM Jan 12 16:16:13 x haproxy[5204]: [WARNING] 011/161613 (5204) : All workers exited. Exiting... (134) -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Clean up "type: feature" in the tracker
On Tue, Jan 12, 2021 at 01:34:08PM +0100, Tim Düsterhus wrote: > I'm not sure that's necessary. For features there IMO only three states: > > - Implemented: Closed + Fixed. > - Not Planned: Closed + No Label. > - Maybe Planned: Open. I'm having a problem with the last one, which is that we're constantly rediscovering some of them, not even knowing if anyone had a look. In theory there should at least be some discussion so it should be visible that there are some comments, but some of them will sometimes drive the discussion into one direction or another without a definitive verdict being given for the feature. Maybe once someone accepts to work on one of them he should self-assign the issue. Over all it's not terribly important though, and the fact that we're discussing how to further refine the process probably indicates that it already works sufficiently well. Willy
Re: Clean up "type: feature" in the tracker
Willy, Am 12.01.21 um 11:49 schrieb Willy Tarreau: >> Maybe it makes sense to look through the list of currently open feature >> requests and close the ones that are very unlikely to be implemented (or >> unlikely to be implemented in the next few years) to clean up the >> tracker a bit. > > Probably that we should indeed do something like that. But once closed > they're harder to find, so maybe we could proceed by adding a page in > the wiki with a few links: > - opened feature requests (not handled yet) > - opened feature requests (in progress) > - closed feature requests (implemented) > - closed feature requests (not implemented or differently) > > And we'd simply tag "fixed" the ones implemented as desired. For the In fact I already did that for all the features I was able to keep track of. See: https://github.com/haproxy/haproxy/issues?q=is%3Aissue+label%3A%22type%3A+feature%22+is%3Aclosed > not-yet vs wip I don't see any currently valid label, which also makes > me think that we could *possibly* benefit from an "in progress" which > is valid both for bugs and features. However one could argue that an > issue without a status label would imply it's in progress, which would > then suggest that we'd need to add a "status: triage" to new features > just like new bugs. I'm not sure that's necessary. For features there IMO only three states: - Implemented: Closed + Fixed. - Not Planned: Closed + No Label. - Maybe Planned: Open. Best regards Tim Düsterhus
Re: Crash when using wlc in multithreaded mode with agent checks (1.8.26).
Sorry to drag up an old thread. But do we have an eta for a new release of version 1.8 that contains the fix? I noticed that the 2.x versions have been updated, and wanted to make sure that 1.8 has not been left out by mistake. Thankyou Mark On Wed, 16 Dec 2020 at 10:03, Peter Statham wrote: > > On Wed, 16 Dec 2020 at 08:40, Christopher Faulet wrote: > > > > Le 11/12/2020 à 21:34, Peter Statham a écrit : > > > > > > The patch seems to fix the issue. > > > > > > > Peter, > > > > The fix was backported to the 1.8. Thanks ! > > > > -- > > Christopher Faulet > > Hello Christopher, > > Thank you for your time finding the cause and the solution to this. > > -- > > Peter Statham > Loadbalancer.org Ltd. > -- Mark Brookes Loadbalancer.org Ltd. www.loadbalancer.org +44 (0)330 380 1064 m...@loadbalancer.org
Re: Clean up "type: feature" in the tracker
Hi Tim, On Sun, Jan 10, 2021 at 04:37:16PM +0100, Tim Düsterhus wrote: > as of right now feature requests make up almost half of the open issues > in the issue tracker (102 / 226). When looking through them I'm seeing a > few that are probably not going to be implemented any time soon (if ever). Yes, I noticed this as well. (...) > Maybe it makes sense to look through the list of currently open feature > requests and close the ones that are very unlikely to be implemented (or > unlikely to be implemented in the next few years) to clean up the > tracker a bit. Probably that we should indeed do something like that. But once closed they're harder to find, so maybe we could proceed by adding a page in the wiki with a few links: - opened feature requests (not handled yet) - opened feature requests (in progress) - closed feature requests (implemented) - closed feature requests (not implemented or differently) And we'd simply tag "fixed" the ones implemented as desired. For the not-yet vs wip I don't see any currently valid label, which also makes me think that we could *possibly* benefit from an "in progress" which is valid both for bugs and features. However one could argue that an issue without a status label would imply it's in progress, which would then suggest that we'd need to add a "status: triage" to new features just like new bugs. Just my two cents, ideas welcome of course! Willy
Bid Writing, Major Donors and Volunteering Workshops
NFP WORKSHOPS Affordable Charity Training Courses 18 Blake Street, York YO1 8QG 01133 280988 Bid Writing: The Basics ONLINE VIA ZOOM COST £95.00 TOPICS COVERED Do you know the most common reasons for rejection? Are you gathering the right evidence? Are you making the right arguments? Are you using the right terminology? Are your numbers right? Are you learning from rejections? Are you assembling the right documents? Do you know how to create a clear and concise standard funding bid? Are you communicating with people or just excluding them? Do you know your own organisation well enough? Are you thinking through your projects carefully enough? Do you know enough about your competitors? Are you answering the questions funders will ask themselves about your application? Are you submitting applications correctly? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to submit grant funding applications to charitable grant making trusts and foundations. People who provide advice to these organisations are also welcome. Bid Writing: Advanced ONLINE VIA ZOOM COST £95.00 TOPICS COVERED Are you applying to the right trusts? Are you applying to enough trusts? Are you asking for the right amount of money? Are you applying in the right ways? Are your projects the most fundable projects? Are you carrying out trust fundraising in a professional way? Are you delegating enough work? Are you highly productive or just very busy? Are you looking for trusts in all the right places? How do you compare with your competitors for funding? Is the rest of your fundraising hampering your bids to trusts? Do you understand what trusts are ideally looking for? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to submit grant funding applications to charitable grant making trusts and foundations. People who provide advice to these organisations are also welcome. Dates & Booking Links BID WRITING: THE BASICS Mon 11 Jan 2021 10.00 to 12.30Booking Link Mon 25 Jan 2021 10.00 to 12.30Booking Link Mon 08 Feb 2021 10.00 to 12.30Booking Link Mon 22 Feb 2021 10.00 to 12.30Booking Link BID WRITING: ADVANCED Tue 12 Jan 2021 10.00 to 12.30Booking Link Tue 26 Jan 2021 10.00 to 12.30Booking Link Tue 09 Feb 2021 10.00 to 12.30Booking Link Tue 23 Feb 2021 10.00 to 12.30Booking Link Recruiting and Managing Volunteers ONLINE VIA ZOOM COST £195 TOPICS COVERED Where do you find volunteers? How do you find the right volunteers? How do you attract volunteers? How do you run volunteer recruitment events? How do you interview volunteers? How do you train volunteers? How do you motivate volunteers? How do you involve volunteers? How do you recognise volunteer? How do you recognise problems with volunteers? How do you learn from volunteer problems? How do you retain volunteers? How do you manage volunteers? What about volunteers and your own staff? What about younger, older and employee volunteers? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to recruit volunteers into their organisation and then manage those volunteers. People who provide advice to these organisations are also welcome. Dates & Booking Links Wed 13 Jan 2021 10.00 to 16.00Booking Link Wed 10 Mar 2021 10.00 to 16.00Booking Link Major Donor Fundraising ONLINE VIA ZOOM COST £95 TOPICS COVERED Major Donor Characteristics, Motivations and Requirements. Researching and Screening Major Donors. Encouraging, Involving and Retaining Major Donors. Building Relationships with Major Donors. Major Donor Events and Activities. Setting Up Major Donor Clubs.Asking For Major Gifts. Looking After and Reporting Back to Major Donors. Delivering on Major Donor Expectations. Showing Your Appreciation to Major Donors. Fundraising Budgets and Committees. PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to carry out Major Donor Fundraising. People who provide advice to these organisations are also welcome. Dates & Booking Links Wed 10 Feb 2021 10.00 to 12.30Booking Link Wed 14 Apr 2021 10.00 to 12.30Booking Link FEEDBACK FROM PAST ATTENDEES AT LIVE WORKSHOPS I must say I was really impressed with the course and the content. My knowledge and confidence has increased hugely. I got a lot from your course and a lot of pointers! I can say after years of fundraising I learnt so much from your bid writing course. It was a very informative day and for someone who has not written bids before I am definitely more confident to get involved with them. I found the workshops very helpful. It is a whole new area for me but the information
