This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: stap vs pgrps
- From: Josh Stone <jistone at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Tue, 31 Mar 2009 17:37:34 -0700
- Subject: Re: stap vs pgrps
- References: <20090331230224.24543FC3BE@magilla.sf.frob.com>
Roland McGrath wrote:
> I won't recapitulate the entire explanation of job control here.
> The basic reality is that if you are not implementing a job control
> shell, then you should not be doing anything at all with pgrp magic.
> This includes ever passing 0 as the first argument to kill. For
> something like stap that wants to be a "normal" tool--can be used
> batch-style inside scripts, or can be used interactively with ^Z,
> stty tostop, et al working normally--changing pgrps is right out.
> Trust Me, this is not the can of droid worms you are looking for.
Indeed, I wish we had asked you about this sooner to avoid the headaches.
> The full bugzilla history is now full of muddled conversations and
> it's hard to sort through what the original real issues were. Can
> someone explain concisely what the real problem was that motivated
> commit 8a3fc6c9, PR6030 in the first place?
The stapgui wanted to SIGTERM stap to finish the run, but this wasn't
passing the SIGTERM to stapio/staprun. Thus, while stap would quit, the
module would still be active.
I think the main source of this grief is that we use system() to spawn
processes, which doesn't give us a way to propagate our signals. I'm
thinking of something like this instead:
int stap_spawn(...) {
posix_spawn(&pid, ...);
while (1) {
pid_ret = waitpid(&pid, &status, 0);
if (pid_ret == pid)
return WIFEXITED(status) ? WEXITSTATUS(status) : -1;
if (errno == EINTR)
kill(pid, SIGTERM);
else
return -1;
}
}
Does that look sane?
Josh