Hello, I see now that a number of emails have the patch in the body. So
doing that now
---
doc/configuration.txt | 7 +++++++
doc/management.txt | 5 +++++
src/haproxy.c | 19 +++++++++++++++++++
3 files changed, 31 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index a8e5192b1..b8624fc19 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -3079,6 +3079,13 @@ nbthread <number>
output of "haproxy -vv". Note that values set here or automatically
detected
are subject to the limit set by "thread-hard-limit" (if set).
+ On Linux and macOS, each thread is assigned an operating-system-visible
name
+ of the form "haproxy-N", where N starts at 1 and matches the thread
number
+ reported by the Runtime API "show threads" command. These names help
identify
+ individual threads in system monitors, profilers, debuggers, and crash
dumps.
+ They do not affect scheduling or CPU affinity. Other supported platforms
may
+ continue to display the process name for every thread.
+
numa-cpu-mapping
When running on a NUMA-aware platform, this enables the "cpu-policy"
directive to inspect the topology and figure the best set of CPUs to use
and
diff --git a/doc/management.txt b/doc/management.txt
index 6cd2f4270..dc186dbfc 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -4319,6 +4319,11 @@ show threads
alone, it's a different bug like a corrupted list. In all cases the
process
needs is not fully functional anymore and needs to be restarted.
+ On Linux and macOS, the operating-system-visible thread name is
"haproxy-N",
+ where N is the thread number used by this output. This makes it possible
to
+ correlate a thread shown by system monitors, profilers, debuggers, or
crash
+ dumps with its corresponding block in this command's output.
+
The output format is purposely not documented so that it can easily
evolve as
new needs are identified, without having to maintain any form of
backwards
compatibility, and just like with "show activity", the values are
meaningless
diff --git a/src/haproxy.c b/src/haproxy.c
index b242be44b..58f342f02 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -3110,6 +3110,24 @@ void run_poll_loop()
_HA_ATOMIC_AND(&th_ctx->flags, ~TH_FL_IN_LOOP);
}
+#if defined(USE_THREAD) && (defined(__linux__) || defined(__APPLE__))
+static void set_thread_name(void)
+{
+ char name[16];
+
+ snprintf(name, sizeof(name), "haproxy-%u", tid + 1);
+#if defined(__APPLE__)
+ pthread_setname_np(name);
+#else
+ pthread_setname_np(pthread_self(), name);
+#endif
+}
+#else
+static inline void set_thread_name(void)
+{
+}
+#endif
+
void *run_thread_poll_loop(void *data)
{
struct per_thread_alloc_fct *ptaf;
@@ -3121,6 +3139,7 @@ void *run_thread_poll_loop(void *data)
__decl_thread(static pthread_cond_t init_cond =
PTHREAD_COND_INITIALIZER);
ha_set_thread(data);
+ set_thread_name();
set_thread_cpu_affinity();
clock_set_local_source();
ha_random_seed_thread();
--
2.55.0
On Wed, Jul 29, 2026 at 10:31 PM Abhishek Chanda <[email protected]>
wrote:
> Hello all,
>
> We run haproxy in front of postgres. While debugging some connection
> issues with linux tools, we noticed that all the threads were using the
> same name. This made debugging difficult. Attaching a patch that changes
> haproxy to set unique thread names. I tested this manually on OSX. This
> should make debugging this much easier. Please let me know if anything
> should be changed.
>
> Thanks
> --
> Thanks and regards
> Abhishek Chanda
>
--
Thanks and regards
Abhishek Chanda
