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 hangingOn 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 recursbefore we kill the listener and restart it?Solaris 2.8 Oracle 188.8.131.52 <http://184.108.40.206>