On Wed, Feb 25, 2026 at 05:25:05PM +0100, Willy Tarreau wrote: > On Wed, Feb 25, 2026 at 04:22:04PM +0000, Egor Shestakov wrote: > > Hi Willy! > > > > On Wed, Feb 25, 2026 at 08:54:08AM +0100, Willy Tarreau wrote: > > > That's a good point, however it will not help the users locate the right > > > tunable either. I think it can be useful to print actconn, which is the > > > number of active front connections and can definitely give a hint about > > > a limit that might have been encountered (e.g. if you see 125000, it > > > instantly rules out any lower threshold). You can log it as "actconn=" > > > since it's already mentioned in the doc about log formats. > > > > > > > Do you mean print the actconn in both cases? I understand it for ENFILE, > > because the actconn, which is almost at the system limits, eliminates all > > doubts. I suppose that ENOMEM is mostly caused by a large number of opened > > FDs and printing this number can be useful, but I feel some lack of > > coherency between actconn and ENOMEM. > > Yes it can be useful because it gives a hint about the possible cause for > ENOMEM. We've seen allocation error cases in environments trying to boot > with super high limits for example. In the event the limit remains high > but still allows to boot, it could be conceivable that an allocation > failure happens during a DoS. In that case you'd probably be happy to > see with ENOMEM that you already had 12 million connections.
Thanks for demystifying, Willy:) -- >8 --
