On Wed, 24 Oct 2007 09:03:20 -0400 "Brett McCoy" <[EMAIL PROTECTED]> wrote:
> This is somewhat off-topic here, you may want to talk to a Linux list > for better answers. > > > I am writing an application in Linux OS using C++. It is getting > > killed in a mysterious way during interactions with a removable > > storage media. I wrote a signal handler for all the possible Linux > > signals, but signal handler is not getting called. > > It's possible the program is crashing and not being killed in the > normal fashion > > > To solve this problem, I want to know these things with respect to > > Linux OS: > > > > 1) Is it possible to kill a process without sending any signal to > > it? > > Well, a process can be killed by something bad like a segmentation > fault or similar extreme situation. > > > 2) If answer to 1 is yes, how to kill without sending any signal? > > 3) If answer to 1 is yes, how can the process getting killed know > > the way in which it is being killed? > > There are several signals that are used to kill a process -- SIGQUIT, > SIGTERM, SIGKILL, SIGABORT are the main ones. SIGSEGV, SIGFPE, SIGILL > can also bring a program to its knees. SIGKILL is the only one you > can't catch or ignore. > > > 4) If I kill a process by sending SIGKILL to that process, is there > > any way for that process to know that it got killed by SIGKILL? > > No, you can't catch or ignore SIGKILL (signal 9). > > > 5) What other debugging methods can I follow to know the reason for > > crash? (I can't obtain core dump or run debugger due to hardware > > limitations. I can get log statements) > > What hardware limitations? If you can't use a debugger or use a core > dump, then you will have to debug by logging the internal state of the > program. Sorry, just being finicky, but there is a situation where the signal will not be handled and the process will not be killed. It can be in state uninteruptable and then the only way to forcefully remove it is to reboot. There is a possibility that sending it OOM with magic sysreq could be of assistance, but that's not certain to kill it off. -- The dual T1 to the PS2 is toast because of a mistake. The Empire is port scanning the entire /16. :: http://www.s5h.net/ :: http://www.s5h.net/gpg [Non-text portions of this message have been removed]
