This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: staprun -c deadlocks often
- From: Josh Stone <jistone at redhat dot com>
- To: "Richard W.M. Jones" <rjones at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 17 Jun 2011 14:09:03 -0700
- Subject: Re: staprun -c deadlocks often
- References: <20110617154320.GC18438@amd.home.annexia.org>
On 06/17/2011 08:43 AM, Richard W.M. Jones wrote:
> When it hangs, a process listing shows:
>
> 13073 pts/4 Ss 0:00 \_ bash
> 17930 pts/4 S+ 0:00 | \_ sudo staprun -o /tmp/stap -c /bin/ls /home/rjones/.systemtap/cache/44/stap_44fe38ee6f62656645948ce5d275d678_260427.ko
> 17931 pts/4 Sl+ 0:00 | \_ /usr/libexec/systemtap/stapio -o /tmp/stap -c /bin/ls /home/rjones/.systemtap/cache/44/stap_44fe38ee6f62656645948ce5d275d678_260427.ko
> 17932 pts/4 S+ 0:00 | \_ /usr/libexec/systemtap/stapio -o /tmp/stap -c /bin/ls /home/rjones/.systemtap/cache/44/stap_44fe38ee6f62656645948ce5d275d678_260427.ko
>
> Note that there is no staprun process, nor any /bin/ls, but two stapio
> processes have been left around.
It's not surprising that staprun is gone -- once it has loaded the
module, it execs stapio to drop privileges while the script runs. It
doesn't make any difference here since you're running with sudo, but if
you add yourself to stapusr & stapdev groups and let the setuid staprun
do its thing, then stapio and the -c child will run as your own uid.
Having two stapios supports Frank that this is likely PR10189. We first
fork stapio so we can report the child's pid to the module, then wait
for the module's STP_START message before the actual child exec. If
there's no message, we make no progress...
Josh