SIGKILL termination application

[Sup]

Hi,

We are running a application, which is terminating due to signal 9. As for as I know no one issued "kill -9 pid". Is anybody have any idea Where/Why signal -9 coming from.

Application goes down with following message.

process termination: abnormal termination, signal number was 9.

Thanx

[Ross Zubritski]

What is the application? A signal with that particular switch (-9) must be hard coded somewhere in the app.

RZ

[Chris Vail]

Only root, or the owner of a process can kill it. For example, the oracle user can kill any oracle process, but root can kill any process at any time.

There are some exceptions to this rule, but these are related as to whether or not the process actually dies. There are some situations where killing a process causes a child process to hang, and there are some system level processes which cannot be killed.

Run man kill for details.


Chris

[Ralph Grothe]

A SIGKILL or No. 9 should really be the last resort to shoot a process after nothing else worked, since it doesn't give the process the chance to terminate tidy.

caveat data corruption.

[A. Clay Stephenson]

I would look for crontab entries or /sbin/init.d scripts. I suspect that a daemon is running that looks for a number of related processes and if one of them is missing, it kills the others so that the processes can be restarted. As mentioned, it is very dumb to issue a kill -9.

[Adam J Markiewicz]

Check also applications logs.

It is possible that programmers decided that in very panical situation application should terminate itself with SIGKILL (although, as said, its not very clever). If so there's nothing you can do.

Good luck

Adam

[doug hosking]

There are a few cases where the kernel will initiate process terminations with signal 9 (as opposed to being asked to do them by a kill() system call). These are relatively rare, and occur in cases where the kernel figures out the process is in such a bad state that there is no point in (or sometimes method of)
passing an error back to it. An example might be an I/O error on swapping the process. The kernel knows the process is too ill to continue, but the system as a whole isn't so damaged that a panic is warranted, so only that one process is killed. I'd suggest using dmesg or looking at the syslog files to see if there are any messages there that give hints about such problems.

Another example of where this can happen is on HP-UX 11i systems that have the kernel tunable 'executable_stack' set to 0. Any attempt to execute instructions located on the program stack in this case would cause the kernel to print error messages to the user's tty and system console, warning of the possibility of a buffer overflow attack. The kernel would then send a SIGKILL to the process in question. If you're hitting this case with a legitimately run application, see the '+es' option of the chatr man page for
additional information.

Certainly there are other explanations for who is killing the process. It's awfully hard to guess without being able look at log files, etc. These are at least a few possible causes.

[Wilfred Chau_1]

Hi,
Try this:
# kill -l

This will list all numbers with their associated named. -l is a letter. Not the number 1.

Regards
Wilfred.