Hello Abhishek,
On Wed, Jul 29, 2026 at 10:31:28PM -0500, Abhishek Chanda 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 for this, this is indeed quite interesting.
However I noticed a problem with it: it also changes the name seen by
some tools like "killall", making it impossible to touch the started
command:
$ ./haproxy -db -f foo.cfg &
[1] 31906
$ pgrep '^haproxy$'
$ pgrep '^haproxy-1$'
31906
$ pgrep '^haproxy-2$'
$ killall haproxy
haproxy: no process found
$ killall haproxy-1
[1]+ Terminated ./haproxy -db -f foo.cfg
$
Worse, it even affects processes started under different names:
$ ./haterm -L :8001 &
[1] 32250
$ killall haterm
haterm: no process found
$ killall haterm-1
haterm-1: no process found
$ killall haproxy-1
$
[1]+ Terminated ./haterm -L :8001
So I guess that the right thing to do would be to use
pthread_getname_np() to retrieve the first thread's name, and use that
as a radix to append "-%d" for threads 2-N. This would leave thread 1's
name unchanged (the exact same that was used to start the program),
which would permit to continue to manage the process, and would rename
other ones.
By the way, I noticed that pthread_setname_np() and pthread_getname_np()
also exist on freebsd, and seem to work exactly like Linux, so it might
be worth adding FreeBSD to the #ifdef list.
Also I'm wondering if we can do something to disable it in case it breaks
the build on some platforms, but apparently glibc has had support for
this since 2.12 (2010) and musl since 2017. Thus I guess that for now
it can be considered acceptable, and if someone faces issues in an older
environment we'll find a way to detect/disable it.
Another point, I've just tried to get gdb to report the thread names
but it doesn't (linux + gdb 16.3 here):
[Current thread is 1 (Thread 0x7fec6f8529c0 (LWP 468))]
(gdb) info thread
Id Target Id Frame
* 1 Thread 0x7fec6f8529c0 (LWP 468) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
2 Thread 0x7fec677fe640 (LWP 481) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
3 Thread 0x7fec67fff640 (LWP 480) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
4 Thread 0x7fec66ffd640 (LWP 482) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
5 Thread 0x7fec6f3a8640 (LWP 475) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
6 Thread 0x7fec6dfba640 (LWP 477) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
7 Thread 0x7fec6cf56640 (LWP 479) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
8 Thread 0x7fec6d7b9640 (LWP 478) 0x00007fec6f4b47d6 in epoll_wait ()
from /lib64/libc.so.6
I don't know if you found a way to make this work. It's also said that
prctl(PR_SET_NAME) would be used but I haven't tried it.
Thanks,
Willy
