Anyone tried SystemTap with the latest RHEL5 Beta refresh

[Vara Prasad]

David Smith wrote:

> David Wilder wrote:
>
>> David Smith wrote:
>>
>>> David Wilder wrote:
>>>
>>>> Frank Ch. Eigler wrote:
>>>>
>>>>> "Ken Robson" <ken@odtv.com> writes:
>>>>>
>>>>>  
>>>>>
>>>>> [snip]
>>>>
>>>> But it wont solve the problem of simplifying the use of systemtap 
>>>> for the customers. From a support standpoint if a customer system 
>>>> is missing a debug tool (or some dependent component) the tool may 
>>>> as well not exist! If it comes down to fix the debug tool or find 
>>>> another approach to solve the customers problem the later will 
>>>> generally win. To make stap successful we need to get people using 
>>>> it and providing feedback, let's make it as easy as possible to 
>>>> use. All dependencies must be installed when selecting a product 
>>>> for install.
>>>
>>>
>>>
>>> In general, I certainly agree with you that all dependencies must be 
>>> installed.
>>>
>>> However, systemtap (and any other program that would like to use 
>>> debuginfo) is a special case.  From my understanding, there is a 
>>> policy (perhaps unwritten) that no rpm can require a debuginfo rpm.  
>>> Plus, even if we did require the debuginfo rpm, it still wouldn't 
>>> get installed automatically.  For FC[56], the debuginfo yum 
>>> repositories are disabled by default.  For RHEL[34], the debuginfo 
>>> RPMs aren't available from a RHN channel, they have to be downloaded 
>>> separately (from my vague understanding which could be wrong).  In 
>>> addition, debuginfo RPMs are not present on RHEL/FC install media.  
>>> So, from a current logistical point of view, if the systemtap RPM 
>>> required the kernel debuginfo RPM, systemtap itself could never be 
>>> installed because of missing dependencies that could never be met.
>>>
>>> Currently, using systemtap isn't much different than using gdb.  
>>> Let's assume that /bin/ls keeps crashing on you for some strange 
>>> reason that you'd like to debug.  You are going to need to 
>>> download/install the coreutils debuginfo RPM, then use gdb to debug 
>>> your problem.
>>>
>> Yea but gdb has other uses then debugging coreutils.  SystemTap is 
>> only used to instrument the kernel.
>
>
> gdb is used to debug user apps.  If you compiled the app yourself, 
> you've got the debuginfo (assuming you compiled with '-g').  If you 
> are debugging a vendor compiled app, you'll need to download the 
> associated debuginfo RPM.

gdb is a debugger and SystemTap is just not a debugger and it is much 
more than that.

>
> systemtap is used to instrument the kernel.  

No, it is much more. SystemTap is used instrument entire software stack 
all the way from interpreted applications to device driver interface 
level. Agree we don't have support for user space apps right now but it 
is coming soon so we need to design/package with end goal in mind.

The second major difference is the audience of SystemTap is just not 
developers it is useful all the way from end user (sys admins), to 
service team, app. developers and kernel developers.

> If you compiled your own kernel, you've got the debuginfo (assuming 
> you compiled with '-g').  If you are instrumenting a vendor compiled 
> kernel, you'll need to download the associated debuginfo RPM.
>
Developers have the luxury to debug in their own environment where they 
can reboot at their will most other class of users of system don't have 
such luxury and i think we need to make life easy for others more than 
developers.

If i am a sysadmin and i want to use some scripts that i have developed 
or got it through some trusted source i should have the system fully 
ready to execute my scripts, i don't have to go through hoops to run my 
script.

If i am a service person when i am working under tight deadlines to fix 
the problem if the tool i would like to use is not there it is not 
productive to go through setup of the tool instead other methods will be 
used, which means SystemTap is not used to its potential.

bye,
Vara Prasad