On Fri, Nov 15, 2024 at 02:25:14PM +0100, Florian Piekert via Postfix-users
wrote:
> the problem surely is on my end. But where and why. Maybe someone has an idea.
What problem exactly?
> -all three have in master.cf for tlsproxy the -D parameter at the end
Why?
> -all three have same debugger_command in main.cf
Why?
> ALL 3 core dump on tlsproxy now and then.
Do you have a backtrace from such a core dump?
> 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.
That's not a core dump, that's logging of a debugger attaching to and
continuing a process, which subsequently exits normally.
Is there any evidence of actual crashes?
> Why get the tlsproxy.<pid>.log files dumped, what is the reason for
> it? Isn't it something that the tlsproxy process should handle?
Presumably, your debugger command arranges to record its interaction
with each process in some file, so if anything did go wrong, you'd be
able to find out.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
