Re: smtp dying

[Victor Duchovni <Victor.Duchovni@xxxxxxxxxxxxxxxxx>]

On Wed, Sep 01, 2004 at 06:38:02PM +0200, Pavel Urban wrote:

> Victor Duchovni wrote:
> >On Wed, Sep 01, 2004 at 10:06:48AM +0200, Pavel Urban wrote:
> >>Too bad, the newest RPM exhibits the same behaviour. Anybody else seen 
> >>problems with TLS-enabled Postfix on RH ES 3?
> >>
> >
> >
> >The only way to get at the real problem is to get a stack trace.
> >
> >	http://www.postfix.org/DEBUG_README.html
> >	http://www.postfix.org/postconf.5.html#debugger_command
> >
> >read about the "-D" switch, some familiarity with Unix debuggers
> >required...
> >
> 
> *sigh* I was afraid somebody says so. The problem is that this behaviour 
> is not so frequent and the box is quite loaded... but I'll try it. I was 
> hoping that somebody already met this problem. Well, thanks, I'll be back!
> 

A simple tool for finding rare signal problems (on Solaris) is:

    truss -SSIGFOO -t '!all' -p $pid

the overhead is modest, and any stopped processes can be examined with
gcore or a debugger still in their live (stopped) state. Just run "ps"
periodically looking for a stopped process other than "sched"

    sh# ps -e -o status,pid,comm | awk '$1 == T && $2 != 0 {print}'

when you find it, gcore, gdb /usr/libexec/postfix/smtp -p $pid, ...

On other systems you may need to go the debugger_command route. The
tricky part is getting the gdb script to work correctly, but the
overhead is again low...

-- 
	Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@xxxxxxxxxxx?body=unsubscribe%20postfix-users>