This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Bug runtime/6030] stap, staprun, stapio interaction quirks: stale module left unloaded
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: anithra <anithra at linux dot vnet dot ibm dot com>
- Cc: systemtap <systemtap at sources dot redhat dot com>
- Date: Thu, 17 Jul 2008 13:46:46 -0400
- Subject: Re: [Bug runtime/6030] stap, staprun, stapio interaction quirks: stale module left unloaded
- References: <20080404085514.6030.ananth@in.ibm.com> <20080710170428.32479.qmail@sourceware.org> <487F33EE.9050809@linux.vnet.ibm.com>
anithra <anithra@linux.vnet.ibm.com> writes:
> [...] kill(SIGTERM, -stap_pid) solves the problem from the StapGUI
> point of qview. I'm able to terminate both the stap& stapio process
> and thereby unload the module.
Good.
> But the behaviour of the stap process still doesn't seem correct. If
> a signal is sent to the stap process it terminates leaving stapio
> running as a zombie and the module still loaded.
I still don't quite see how this scenario would happen. If stapio is
a zombie, then this means that it has exited. As a part of exiting,
stapio attempts to exec "staprun -d MODULE" to unload the module. If
a module is left behind loaded, something other than stap process's
own signal processing must have been involved.
(By the way, there is no such thing as "running as a zombie". Zombie
processes are unsightly but otherwise consume essentially no
resources.)
- FChE