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]

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


------- Additional Comments From anithra at linux dot vnet dot ibm dot com  2008-07-07 20:31 -------
(In reply to comment #5)
> (In reply to comment #3)
> > 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.
> 
> Remember, the scenario here is that the user killed his own stap*
> processes with kill -9.  Such extreme annoyance is self-induced.
> 
> I recall we came across some runes that perform pseudo-renaming of a
> compiled module before insmod time.  If that can be made to work
> (as a part of staprun presumably), then reexecuting the same probe
> several times concurrently would be possible.
> 
> Another simple possibility is for staprun to attempt to *unload* a
> module with the same name that it's about to load - to clean up an
> orphaned zombie.  (It'd use sys_delete_module(2) with O_NONBLOCK.)
> 
> 
> > 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.   [...]
> 
> Perhaps, but is it useful & necessary enough to overcome the natural
> skepticism toward adding anything setuid?
> 

Due to the above sequence of signals when an user attempts to kill the stap
process by sending a signal (not counting -9), the stap process terminates when
pending_interrrupts > 1 , leaving the stapio as a zombie. I'm not sure why it
was designed this way, but i'm facing problems when terminating a stap process
from the stapgui due to this. 
The stapgui execs stap process' upon a user's request but it is not possible to
terminate these processes as we are not aware of the pid of the stapio process.
We only have the pid of the stap process but terminating that would leave the
stapio running as a zombie and the module unloaded. 
This can be fixed by passing the signal to the process group (staprun/stapio)
when pending_interrupts > 1. Thus when stap terminates, so will the staprun/stapio. 
Also, do we need to wait for pending_interrupts to be > 1 even after the script
has started execution (i.e, pass 5)?. 


-- 


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.


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