ll

[ggursel]

Hi all
I have a big and rare problem that I can't solve.
A record is locked and get a message like
<tablename> in use by ,xxx on <servername> xxx. Wait or press CTRL-C to stop

then I kill the locking process either by proshut command or by "kill -9" unix command. The result is surpising. I see in Unix the process is killed. But I still get the same message and cannot use the record. Moreover I see from the _lock table the record is locked. I need your help about conquering this sitation.
The only solution I developed to overcome this is restarting the database (The worst one).

 

[ggursel]

The subject is changed by itself and can^t adjust it

 

[Lee Curzon]

Quick observation:

or by "kill -9" unix command.

Don't use this. See:

http://www.greenfieldtech.com/articles/traps_and_kills.shtml

Also KB12968
Guidelines to use of UNIX kill command to stop a process

[Having problems with online KB today]

Guidelines to use of UNIX kill command to stop a process

(Currently under review and edit.) 05 July 94


Use the following options when you use the UNIX kill command to
cancel a defunct process or to release shared memory. Issue these
kills in the following order until you successfully kill the process.

- 1 (SIGHUP) terminal hang up signal
- 2 (SIGINT) same as doing a Ctrl+C, terminal interrupt;
-15 (SIGTERM) default if unspecified is a software termination
likely to release the lock and shared memory being held;
- 8 (SIGQUIT) won't free the lock but produces a memory dump
named core in the directory in which the session was started.
- 9 (SIGKILL) which truly kills the process and requires the
release of held semaphores and shared memory segments for both
the user sessions and the broker process (see kBase entry 3246
"ipcs & ipcrm: Check active message q's, memory, semaphores).

Subject: Using kill -9 on Unix systems

It is not a good idea to "throw the big red switch" since
most systems with their buffered filesystems can get into
real trouble. However, in some cases it is better to
perform a clean reboot of the system than to start randomly
killing processes. Since UNIX does not allow *any* program
to detect a kill -9, the PROGRESS server processes cannot
detect what is happening when processes start to disappear
with kill -9.

Depending on the which process is killed off and what the
process is doing, PROGRESS could eventually figure out
something is wrong and shutdown the database, but if enough
processes are killed off the remaining processes can
effectively "hang" since they could be waiting for some
resource that will never be released by a lost process.

If proshut doesn't seem to work and you are not comfortable
killing things off and cleaning up shared memory,
then reboot the system.

Progress Software Technical Support Note # 12968