lkml.org 
[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: CPU hogs ignoring SIGTERM (unkillable processes)
On 16 Nov 2004 at 11:42, Andreas Schwab wrote:

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>
> > On 15 Nov 2004 at 14:39, Andreas Schwab wrote:
> >
> >> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> >>
> >> > Hello,
> >> >
> >> > today I've discovered a programming error in one of my programs (that's fixed
> >> > already). When trying to replace the binary, I found out that the processes seem
> >> > unaffected by a plain "kill": They just continue to consume CPU. However, a "kill
> >> > -9" terminates them. ist that intended behavior? I guess not. Here are some facts:
> >>
> >> Are you sure it doesn't block or ignore the signal?
> >
> > Andreas,
> >
> > I don't mess with signals (as said);
>
> That is not required. It could just as well inherit the setting from the
> parent.

OOps! Now that you are telling me, I realize that the program that hung was
actually started by a shell script that was in turn exec'd() (after a fork()) from
a truly multi-threaded application.

I couldn't capture the binary via "ps -axs", because it's terribly efficient, but
I managed to captue the shell script that way:

UID PID PENDING BLOCKED IGNORED CAUGHT
STAT TTY TIME COMMAND
2 7792 0000000000000000 0000000080014003 8000000000001004 0000000000010002 S
? 0:00 /bin/sh /usr/local/milter/Sopho

The manpage on execve() isn't too verbose on the topic:

...
execve() does not return on success, and the text, data,
bss, and stack of the calling process are overwritten by
that of the program loaded. The program invoked inherits
the calling process's PID, and any open file descriptors
that are not set to close on exec. Signals pending on the
calling process are cleared. Any signals set to be caught
by the calling process are reset to their default
behaviour. The SIGCHLD signal (when set to SIG_IGN) may
or may not be reset to SIG_DFL.
...

"Yet Another UNIX-like OS" dared to state in the man page:

The processing of signals by the process is unchanged by exec*(),
except that signals caught by the process are set to their default
values (see signal(2)).

However the same man page states that pending signals are not cleared.
Interesting.

The process also retains the following attributes:

...
+ pending signals
...

This is the rerason for returning the following errno, I guess:

[EINTR] A signal was caught during the exec*() system
call.


Let me summarize: The Kernel has no problem, just the docs ;-) Prpgrammers are fed
with docs of course...

Thanks and regards,
Ulrich Windl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.040 / U:1.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site