This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stap vs pgrps


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]