Hi William, I have been investigating the backport situation a bit and I wanted to quickly share some findings that might be useful.
So, I noticed a difference regarding the process list before version 3.0, which would need to be accounted for. "show proc" still uses the default parser here, which leaves appctx->svcctx uninitialized: https://github.com/haproxy/haproxy/blob/f76e73511addd075f556449b0ebf33c9f7a5184b/src/mworker.c#L803C100-L803C117 Therefore, additional context would be needed like in the patch below where also the custom parser method needs to be copied from master. Furthermore, from what I can see the process list works a bit differently when it comes to reloads, using a min counter: https://github.com/haproxy/haproxy/blob/f76e73511addd075f556449b0ebf33c9f7a5184b/src/mworker.c#L174 With the 1:1 logic from master, I again run into duplicates and messed up ordering in the the "show proc" output. I had success fixing this by adjusting the iteration, replacing ctx->next_reload = child->reloads with ctx->next_reload = child->reloads + 1; and replace if (ctx->next_reload && child->reloads >= ctx->next_reload) continue; with if (ctx->next_reload && child->reloads < ctx->next_reload) continue; in the old worker part. I appended the resulting patch which directly applies to 3.0-dev13 (just as an example, not fully ready for a commit yet). With this, it works very well for me for the backport targets 2.8 and 3.0 (deferred from the issue https://github.com/haproxy/haproxy/issues/3204). I hope this helps, I am also curious whether you agree with my approach here. Thanks in advance, and best regards, Alexander -----Original Message----- From: William Lallemand <[email protected]> Sent: Monday, 5 January 2026 09:04 To: Stephan, Alexander <[email protected]> Cc: [email protected] Subject: Re: BUG/MINOR: mworker/cli: avoid duplicates in 'show proc' [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Tue, Dec 30, 2025 at 02:45:53PM +0000, Stephan, Alexander wrote: > Hi Willy and William, > > First, sorry for the delay. I hope you had nice holidays! > Thanks for the feedback and happy to hear you like the refactor in general! > Using the reload counter is a very neat idea. So, I played around with > my test setup, and yes, from what I found out, it works very well. 😊 > > > We probably don't need that if using the reload field instead of the > > timestamps. > > In my opinion, there is also no need for the separate index. I did extensive > testing here, I don't could trigger any such issue where it would become > necessary. > The reload counter is actually strictly monotonic. So, the approach turns > out to be quite elegant. > > So, appended you can find the updated set of patches using the discussed > reload approach. > The code changes touch surprisingly little lines of code. > Again, please let me know what you think. > > Thanks, and best, > > Alexander > Hello Alexander, Thank you, looks like the good approach indeed, I merged the patch in master! Regards, -- William Lallemand
show-proc-3.0-dev13.patch
Description: show-proc-3.0-dev13.patch
