Hi William, On Wed, Jan 13, 2021 at 08:57:47AM +0100, William Dauchy wrote: > 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 <[email protected]> > > 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 <[email protected]> >
Apologies for forgetting about adding this in my commit message. Out of curiosity which use case is currently covered for you ? I did most of my testing on the number of FD and wasn't able to confirm that only startup is broken, and reload behaves as expected. Either way I first get alerted, then warned, and I have a new haproxy process with not so strict limits. -- Jérôme
