Hello again on this topic,
the problem surely is on my end. But where and why. Maybe someone has an idea.
Situation:
-3 cloud machines with ubuntu 24.04.1 LTS (2 dist upgraded from 22.04.1 LTS, 1
plain 24.04.1 LTS out of the box)
-all three have postfix 3.10-20241113 snapshot
-2 out of 3 use tlsrpt (configured, compiled, installed)
-1 has nothing regarding tlsrpt, not configured or compiled for pf, no main.cf
directives, nothing except the 3.10-20241113 snapshot.
-all three have in master.cf for tlsproxy the -D parameter at the end
-all three have same debugger_command in main.cf
ALL 3 core dump on tlsproxy now and then.
With the debug info from the below machine, all we saw was
...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007ef763d107a7 in __GI___wait4 (pid=2071406,
stat_loc=stat_loc@entry=0x7ffc19aa78a8, options=options@entry=0,
usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
(gdb) Continuing.
[Inferior 1 (process 2071405) exited normally]
as last dump info of gdb.
All have the same lib, same date, same size.
root@butterfly:~# l /lib/x86_64-linux-gnu/libthr*
lrwxrwxrwx 1 root root 17 Aug 8 16:47 /lib/x86_64-linux-gnu/libthread_db.so
-> libthread_db.so.1
-rw-r--r-- 1 root root 47912 Aug 8 16:47
/lib/x86_64-linux-gnu/libthread_db.so.1
Why get the tlsproxy.<pid>.log files dumped, what is the reason for it? Isn't
it something that the tlsproxy process should handle?
Florian
That was not very useful.
Next experiment:
- Build Postfix like you built it before we started messing with debuggers.
- But this time don't add -DUSE_TLSRPT in the CFLAGS.
- As usual: make upgrade, postfix reload.
If this build also crashes, then the problem is at your end.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
