Re: Diagnosing a listener problem?

For clarification, you can set TRACE_LEVEL_LISTENER and other parameters to various values to obtain different levels of trace information on the listener. You can also enable tracing on a running listener with the lsnrctl utility. See Metalink DocID 219968.1 .
For Solaris truss, you would be doing something like truss -fp <pid> where pid is the tnslsnr process.
As mentioned below, it is important to distinguish between a hanging process and a spinning one, so that you can characterize the problem to support when you log an SR. Attaching with truss, or even looking at ps or top can answer this question.
Finally, you can obtain a call stack trace of a hanging listener by attaching to the listener with a symbolic debugger, such as gdb. You would do something like gdb $ORACLE_HOME/bin/tnslsnr <pid>, then enter 'bt' at the gdb prompt. You would provide this call stack trace to Oracle if you opened an SR. 

Good luck,

Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net


Stefan Knecht wrote:
There's many ways you can go about to diagnose problems such as this. You might wanna start with: 

- Listener log files
- Enabling TRACE on the listener
- Running an OS trace utitiliy (as truss on sunos) - but make sure it follows fork system calls - and check where lsnrctl exactly hangs - Attach to the hanging listener process using truss - you might not see anything, but if it's stuck inside some loop - you might just see what function call is hanging
On 3/19/07, *Jay.Miller@xxxxxxxxxxxxxxxx <mailto:Jay.Miller@xxxxxxxxxxxxxxxx>* <Jay.Miller@xxxxxxxxxxxxxxxx <mailto:Jay.Miller@xxxxxxxxxxxxxxxx>> wrote: 

    On one of our databases we're having an odd recurring problem.  It
    first happened immediately after a firewall change but has
    recurred twice.


    3 times so far the listener has frozen.  The process is still
    running but no connections are being allowed in and it isn't
    possible to stop the listener using lsnrctl (it just hangs).  We
    need to kill the process and restart it.


    Can anyone suggest any diagnostics to run if the problem recurs
before we kill the listener and restart it? 
    Solaris 2.8

    Oracle 9.2.0.7 <http://9.2.0.7>


--
http://www.freelists.org/webpage/oracle-l

Other related posts: