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


On Tue, 2009-03-31 at 20:16 -0700, Roland McGrath wrote:
> > That's why I do think stap needs to care, rather than trying to pass the
> > buck up to the caller.
> 
> stap is a command-line batch-style program like any other.  It is not
> expected to deal with this for you.  That is just the Unix way.  The
> thing that runs it and wants to send it a SIGTERM is *just wrong* for
> running any normal command-line batch-style program.
> 
> If you are a non-batch thing that runs and controls a batch thing, then you
> are responsible for the fancy magic that "controls" really means.  i.e.,
> you are a job control shell or run one, as inside "expect" or any terminal
> window sort of thing.  (Those use a pty, which is also the only way to be
> right in the face of potential privilege issues.)

But I don't think users see stap as a batch thing, they see it as that
program that provides them the output they want to read interactively.
If they kill/interrupt it, then they expect it to die and clean up after
itself. You expect the same from a python or perl script that you run,
won't you?

> When you have a setuid program you might need to kill, this is really all
> moot.  You don't have to agree with me.  You just can't do it any other
> way.  You're not allowed.  (Find a GUI program that runs "ping" and see
> whether it does some magic or whether it's actually just broken, 'cause
> those are the only two options.)
> [...]
> If one cares about being robust during the "staprun" phase, then this
> really is all moot.  It's setuid and the stap process is not allowed to
> send it any signals with kill.

So, this is basically the original problem statement. Being robust
during the staprun phase. That is what we care about. If someone kills
stap during normal interactive running it (either from a shell, an
external program or a quick and dirty script) we want staprun to

Should we turn all this around? Add a "--watch-parent" argument to
staprun (or maybe --controller <pid>), so that staprun monitors that
process (which normally will just be the interactive stap program) and
then when that process dies for whatever reason cleans up silently.

Cheers,

Mark


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