[Bug runtime/6030] stap, staprun, stapio interaction quirks: stale module left unloaded

["hunt at redhat dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From hunt at redhat dot com  2008-04-04 15:43 -------
Subject: Re:  stap, staprun, stapio interaction quirks:
	stale 	module left unloaded


On Fri, 2008-04-04 at 17:16 +0530, Ananth N Mavinakayanahalli wrote:
> > We cannot reasonably recover from a kill -9 on staprun.  That is the only
> > privileged process that can unload the module.  It may have been hand-started,
> > leaving none of our code available to watch over it and restart it.  Teaching
> > stap to re-fork staprun another time is perhaps possible, but in your
> > "kill -9 stap staprun" scenario, that wouldn't help either.
> 
> Agreed. SIGKILL is a box case. SIGINT/SIGHUP can be handled though.
> 
> > Perhaps it's time to reconsider including a script such as
> > http://sourceware.org/ml/systemtap/2008-q1/msg00051.html
> > in the distribution.  Or a cron-driven systemtap module cleaner/unloader.
> 
> Yeah. That'd work too.

cron wouldn't work well. If you wanted to run the same script you would
not be able to until cron had triggered the cleanup.  As a user, I find
stuff like that extremely annoying.

I still prefer the solution I described here
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5716

"I think a simpler, more secure approach would be to simply separate the
module removal and build it as a standalone suid program.  It would
check the user was in stapusr or stapdev, verify the module that was
requested to be unloaded was a systemtap module, then unload it.  That
allows staprun to do some quick setup, load the module, then drop all
capabilities (if we use them), fork stapio, and exit. Stapio would exec
the module unloader when it got ^C or an exit message from the module."

So staprun goes away and cannot be killed. SIGKILL on stapio would still
leave the module installed, of course. So then you would run the
unloader by hand. What would we call it? staprm?  Or it could just be
staprun with a flag to unload instead of load.

We could add an option to remove all systemtap modules.

Is there a simple way to tell which systemtap scripts are running and
who owns them?  We could easily add that too.






-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6030

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.