Kbase P69391: Client session hangs, but user is still showing in user control table within Promon
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/6/2009 |
|
Status: Verified
SYMPTOM(s):
User is not shown in proshut user list
User is still shown in Promon User Control list
Proshut disconnect user was issued for the user
_progres process is hung
Client process is still running in the UNIX process list
Client PID can be found in the UNIX process list
FACT(s) (Environment):
UNIX
Progress 9.x
OpenEdge 10.x
CAUSE:
Bug# OE00092240
FIX:
Choose one of the following:
1) Apply Service pack 09 if you are on 9.1D
2) Upgrade to 9.1E
3) Upgrade to 10.1A
Attention: Keep in mind that there could be many reasons why a process may not disconnect properly and for this reason the best approach is go gather as much information as possible (especially a process stacktrace) prior to killing the process. It is virtually impossible to determine the cause of the hung process without this information.
Additional signal logging has been implemented in 9.1D09 to assist development with determining what state a hung process is in. This new logging shows development what signals are being sent to a process and how the process is reacting to those signals.
If you experience a hung process, please log a support call with Progress Technical Support prior to disconnecting or killing the process.
If you must disconnect this process immediately, please try to obtain some basic information regarding the process:
1. Gather information regarding latches via Promon:
Run "promon -NL <dbname> | tee promon.txt" -> Type "R&D" -> Type "debghb" -> Type "6" (hidden menu) -> 11. Latch Counts.
NOTE: Check whether that user is shown in the "Owner" column for ANY of the latches. If it is, then killing that user WILL shutdown the database.
2. Obtain the process ID (PID) of the hung process from the promon User Control screen:
Run "promon <dbname>" -> 1. User Control. -> 2. Match a User Number -> <Enter the Hung User's number>.
3. Check using "ps -ef | grep <PID>" to see whether that process is using CPU resources. (substitute "<PID>" for the PID number obtained using step 2 above).
4. Try to obtain a stacktrace from the hung process. There are a couple of the more basic methods of doing this, and the commands available will depend upon what operating system you are using:
kill -s USR1 PID# > pid.txt (most UNIX's)
or
pstack PID# > pid.txt (on Solaris)
Once you have determined whether or not a stacktrace is able to be produced, if one is being generated then please run the command a few times to different files (or append to current file) so that we can capture if the process state is changing.
If kill -s USR1 isn't generating a stacktrace or is hanging and you do not have pstack available, you can try to generate a core file by using "kill -8 <PID>". NOTE: If there were any latches held by this user, then the database will crash when this user dies. This will not corrupt the database, but it will mean that all currently running users will be kicked off and the database will shutdown.
5. Please note what the last thing was that the user was doing. It may be that they turned off their machine or exited their telnet session without first exiting the Progress session. Find out what the Progress session was doing when they terminated the telnet client.
6. Retain the database log file, that should be inclusive of the database startup prior to the issue all the way until after the database shutdown (if applicable).