Kbase P186050: Audit archive process is getting error 12011 due to a locked record.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/04/2011 |
|
Status: Verified
SYMPTOM(s):
Audit archive process is getting error 12011 due to a locked record.
Command getting executed when error is received:
proutil dbname -C auditarchive -U userid -P password -directory
Lock wait timeout of 1800 seconds expired (8812)
Could not find record. Recid <recid>, error number <errno>, return <ret-code>. (12011)
Could not find record. Recid 2756992, error number 8, return -1218. (12011)
Shared memory user is connected to the database and is locking the record mentioned in the 12011 error.
Client process locking the record was a telnet client that appears to have lost its network connection to its parent process.
The PPID (Parent Process ID) for the client session that is locking the record is 1 (init)
Client process is not getting or responding to signals being sent to it.
Client process shows in the User Control Table.
Client process shows in the Lock Table as locking the specific record.
promon cannot disconnect the user.
See signals from proshut being sent to the client when disconnecting the client, but the client process still remains.
ps -elf from UNIX command prompt shows that the process is in a sleeping state.
FACT(s) (Environment):
x86_64 (AMD64/EMT64)
Linux
OpenEdge 10.1C04 Service Pack
OpenEdge Category: Database
CAUSE:
Child process is bound to the init process (PPID 1). This process is no longer accepting or responding to signals therefore it cannot be terminated/disconnected from the database (possibly short of issuing an untrappable "kill" (ie kill -9).
FIX:
Shutdown the database and restart the database. That will prevent the PID from having any relationship to the database when it is restarted.
To get rid of the process from a UNIX system level, a kill -9 at this point could be attempted, however there are some potentially serious consequences of this action, and it should only be taken with a full understanding of what could happen due to the use of this command. For more information see solution, P20737, "Considerations when using the UNIX kill -9 command" .
If the process remains at this point, the only way to remove that PID from a system level would be to either change system run levels (which would cause init to be respawned) or reboot the machine.