This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/6030] stap, staprun, stapio interaction quirks: stale module left unloaded
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 8 Apr 2008 14:12:21 -0000
- Subject: [Bug runtime/6030] stap, staprun, stapio interaction quirks: stale module left unloaded
- References: <20080404085514.6030.ananth@in.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From fche at redhat dot com 2008-04-08 14:12 -------
(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?
--
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.