From: Victor Duchovni (no email)
Date: Wed Sep 01 2004 - 13:07:51 EDT
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:?body=unsubscribe%20postfix-users>
|
|
|