when does the system send SIGKLILL
in [Unix Programming]
|
Prev: Suggestions needed
Next: A tool that suggests optimized logic for a piece of code/module/function
From: William Ahern on 11 Jan 2010 20:43 John Gordon <gordon(a)panix.com> wrote: > In <729a2645-1597-4941-acff-e6aad7db827c(a)p24g2000yqm.googlegroups.com> cerr <ron.eggler(a)gmail.com> writes: > > > My application sometimes randomly receives a SIGKILL signal, gdb would > > say something like: > > Program terminated with signal SIGKILL, Killed. > > The program no longer exists. > > (gdb) > > And i have no clue why? When does the system send a SIGKILL? There is > > no 3rd application send anything to mine.... > > Have you asked the system administrator if they're sending the kill signal? My thoughts, too. Some systems will kill processes owned by a user not currently logged into the system. Or perhaps user processes not attached to a TTY. Whatever the condition, I've been on systems that effectively prevented ordinary users from running daemons for any signficant length of time.
From: guenther on 11 Jan 2010 21:37 On Jan 11, 11:28 am, cerr <ron.egg...(a)gmail.com> wrote: > My application sometimes randomly receives a SIGKILL signal, gdb would > say something like: > Program terminated with signal SIGKILL, Killed. > The program no longer exists. > (gdb) > And i have no clue why? When does the system send a SIGKILL? There is > no 3rd application send anything to mine.... There are situations under which the kernel will send SIGKILL to a process. Others have mentioned the Linux OOM killer; a more rarely seen one is if you have a CPU-time resource hard limit set (such as via the ulimit shell-builtin) then the kernel will send the process a SIGKILL when the limit is reached. Another fairly 'standard' case is when the process tracing another process using ptrace() dies without stopping the tracing; the traced process is sent a SIGKILL then. Since the process in this case is being actively traced with gdb, that would apparently not apply here, but it does explain why killing gdb will kill a process that gdb is attached to. Other possibilities to consider: - bad memory hardware (usually results in SIGSEGVs, but it looks like there are cases where SIGKILL will be generated) - network or pseudo filesystem being ripped out from under the process - hit the SysReq key - various "secure computing" setups which restrict the operations a process can use Good luck! Philip Guenther
From: cerr on 12 Jan 2010 11:32 On Jan 11, 5:43 pm, William Ahern <will...(a)wilbur.25thandClement.com> wrote: > John Gordon <gor...(a)panix.com> wrote: > > In <729a2645-1597-4941-acff-e6aad7db8...(a)p24g2000yqm.googlegroups.com> cerr <ron.egg...(a)gmail.com> writes: > > > > My application sometimes randomly receives a SIGKILL signal, gdb would > > > say something like: > > > Program terminated with signal SIGKILL, Killed. > > > The program no longer exists. > > > (gdb) > > > And i have no clue why? When does the system send a SIGKILL? There is > > > no 3rd application send anything to mine.... > > > Have you asked the system administrator if they're sending the kill signal? > > My thoughts, too. Some systems will kill processes owned by a user not > currently logged into the system. Or perhaps user processes not attached to > a TTY. Whatever the condition, I've been on systems that effectively > prevented ordinary users from running daemons for any signficant length of > time. I'm root and I also - just to make sure no unknown external process would send anything to my device - disconnected the network cable - same behaviour -> SIGKILL
From: cerr on 12 Jan 2010 11:35 On Jan 11, 3:56 pm, David Schwartz <dav...(a)webmaster.com> wrote: > On Jan 11, 3:35 pm, cerr <ron.egg...(a)gmail.com> wrote: > > > The memory seems to be fine with "free" but I just caught a seg fault > > now: > > Program received signal SIGSEGV, Segmentation fault. > > 0x0804cb4c in ?? () > > Then I tried to get a backtrace with bt but i only got: > > (gdb) bt > > #0 0x0804cb4c in ?? () > > how come? I am in the source directory and i disd compile the binary > > with -ggdb3 > > Did you 'strip' your executable or ask your linker to do it? > > Did you pass 'gdb' the executable and make sure it's the exact same > executable as the one that was running? > > DS How would I pass GDB the executable? I just ran gdb out of the source directory where the compiled binary is located as well...
From: John Gordon on 12 Jan 2010 11:36
In <61358e14-656c-4ae6-b57c-5723dd1d25b1(a)j5g2000yqm.googlegroups.com> cerr <ron.eggler(a)gmail.com> writes: > I'm root and I also - just to make sure no unknown external process > would send anything to my device - disconnected the network cable - > same behaviour -> SIGKILL How long does the application run before it gets killed? -- John Gordon A is for Amy, who fell down the stairs gordon(a)panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" |