Hello Viktor, all,
OK, so the "normal exit" isn't a problem then at all?
That is indeed good news, as I thought it was pointing to an issue I have on
these machines. Core dump might have been wrong terminology, process logging
then as you explained.
...
-all three have in master.cf for tlsproxy the -D parameter at the end
Why?
To figure out whats happening and have these log "dumps".
-all three have same debugger_command in main.cf
Why?
Phew, was there forever since 0.x... never bothered about it and only came to
work with the -D in master.cf.
ALL 3 core dump on tlsproxy now and then.
Do you have a backtrace from such a core dump?
see below.
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?
Not anymore after the 1113 fix.
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.
Thanks!! Makes my day now :-)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
