kill 0 works!

[Bill McNAMARA_1]

I was trying to kill -3 an app to get a core dump, but it did nothing.. the app must be trapping.. it's a java process btw.

I need to get the thing to core, so was playing around with kill, accidently instead of kill -0 pid, I typed kill 0 pid and yup the system crashed!

How can I force an app to core dump, God knows it cores when I don't want it to....

Anyway, I recommend using kill with -s!

Thanks all!
Bill

[Alex Glennie · Accepted solution]

kill -6 ?

[Stefan Farrelly]

Ive just tried kill 0 on some of our 11 servers and no crash ! I think you need to update your patches. It certainly shouldnt crash the system.

An application has to be written to handle self-coredumps. Normally it will use one of two signals, SIGUSR1 or SIGUSR2 (see man 5 signal). Its like writing a script using the trap command to trap a certain kill and then process it - ie. coredump or exit or whatever, same for an application. It needs to be setup to handle a particular signal and then dump itself. Normally getting an application provider to do this will prove impossible. Its their application - get them to compile with debug on or fix the dumping problem.

[Volker Borowski]

Hi Bill,
from "man kill" I would suggest "kill -3": should do the job.

Hope this help
Volker

signum signame Name Description
___________________________________________________________________________
0 SIGNULL Null Check access to pid
1 SIGHUP Hangup Terminate; can be trapped
2 SIGINT Interrupt Terminate; can be trapped
3 SIGQUIT Quit Terminate with core dump; can be trapped
9 SIGKILL Kill Forced termination; cannot be trapped
15 SIGTERM Terminate Terminate; can be trapped
24 SIGSTOP Stop Pause the process; cannot be trapped
25 SIGTSTP Terminal stop Pause the process; can be trapped
26 SIGCONT Continue Run a stopped process

[Volker Borowski]

Ok, forget the previous answer.... should have read your question better.

Another option might be to send SIGSEGV (11). In most applications a segmentation violation results in a core.

Hope this helps more :-)
Volker

[Bill McNAMARA_1]

The kill -6 did it.. see below:

# ps -ef | grep java
root 3282 1443 1 13:45:09 ttyp1 0:00 grep java
root 2713 2712 0 13:33:12 ? 0:11 /opt/java1.3/bin/../bin/PA_RISC2
.0/native_threads/java -Xms6
kibo(root) /
# kill -11 2713
kibo(root) /
# ps -ef | grep java
root 2713 2712 0 13:33:12 ? 0:11 /opt/java1.3/bin/../bin/PA_RISC2
.0/native_threads/java -Xms6
root 3285 1443 1 13:45:27 ttyp1 0:00 grep java
kibo(root) /
# kill -6 2713
kibo(root) /
# ps -ef | grep java
root 3288 1443 1 13:45:37 ttyp1 0:00 grep java
root 2713 2712 0 13:33:12 ? 0:13 /opt/java1.3/bin/../bin/PA_RISC2
.0/native_threads/java -Xms6
kibo(root) /
# kill -6 2713
kibo(root) /
# ps -ef | grep java
kibo(root) /
# cd /opt/OCMP/bin
kibo(root) /opt/OCMP/bin
# ll core
-rw------- 1 root sys 240048020 Sep 27 13:45 core
kibo(root) /opt/OCMP/bin
# file core
core: core file from 'java'

The whole purpose of the experiment was to test the gdb reliability:

/opt/langtools/bin/gdb64 /opt/java1.3/jre/bin/PA_RISC2.0/native_threads/java ./c
ore

Detected 32-bit executable.
Invoking /opt/langtools/bin/gdb32.
Wildebeest is free software and you are welcome to distribute copies of
it under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for Wildebeest; type "show warranty"
for details.

Hewlett-Packard Wildebeest 1.0 (based on GDB 4.16)
(built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00)
Copyright 1996, 1997 Free Software Foundation, Inc...
(no debugging symbols found)...
Core was generated by `java'.
Program terminated with signal 6, Aborted.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...#0 0xc01f2740 in _kill () from /usr/lib/libc.2
#0 0xc01f2740 in _kill () from /usr/lib/libc.2
(gdb)


PS: I've applied the following patches and kill 0 pid does not crash the system anymore!

PHCO_21187/ PHKL_20016/ PHKL_22684/ PHKL_24116/
PHCO_23651/ PHKL_21121/ PHKL_23842/ PHKL_24165/
PHKL_18543/ PHKL_22589/ PHKL_24027/ PHKL_24943/

Thanks for your help,
Later,
Bill

[John Bolene]

Curious, 240 meg core file?
What a beast you have or is this normal with java?

[Bill McNAMARA_1]

!! yea, bit of a beast, it's a new telecom product that'll be out soon..

Notice also that after killing java, it respawned (in less than 2 secs)..

Anyway, my role is a consulting one, I'm writing supportability scripts and developing debugging and fault correcting tools... keeps me off the streets out of danger!

Later,
Bill