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]

Re: Anyone tried SystemTap with the latest RHEL5 Beta refresh


This note isn't specific to David's response, I'm just responding to this entire thread with my view... and from my what I see on other platforms...

I suggest ignoring the developer user set. The value of SystemTap is that it can be used in a production environment to observe a running kernel and diagnose performance issues or areas for opportunity to increase performance. Yes, there are dev values but ignore them for the moment - too often these discussion turn to a developer PoV - but think of an admin situation. For every 1 development server/wkstn, there are probably 1,000 production servers out there with admins watching them.

It's absurd to think that an admin who's watching a troubled system will go and install a debuginfo package for the server he's (or she's - to be balanced) watching. Not to mention that installing packages like debuginfo may require approvals beyond just that admins' manager. Maybe in an SMB shop with little formal process it's possible but certainly not in enterprise accounts - heck most don't give their admins root privileges.

It's also absurd to assume he/she will cross compile these scripts locally against a target system. First, there's always the possibility that the cross-compile won't match exactly - how do you probe drivers on a server but not on your workstation? Second, for admins this would be a process of testing different scripts, testing different probe points - an iterative problem analysis situation. Do you really think they're going to compile one script to check A, copy the compiled one to the server, run it on the server, go back to their workstation, re-cross-compile a script to check for B, and copy back to server, repeat for C,D,E,F... It's maddening.

What I think SystemTap needs to be is a defacto tool that is running out of the box with RHEL5.0 (yes, I said 5.0 b/c that's when every admin will get trained on "what's new" in RHEL5). I'm not sure what all the issues are, but it needs to be there and running for every RHEL5.0 user to experience on day 1 without having to install dependencies they don't know about. What happens if stap it is in RHEL5 without debuginfo and the user can't compile their scripts - the manual says it's there, but I have to install more to get what I really need to use? Will they automagically know to install debuginfo? Will they easily find the right one to match their kernel?

I'll give an example - have you used htop? It's cool, in some ways much better than top, but how many people are using it compared to top? Everyone knows every Linux server has top and by default when you open a term on a server you know top is there. That's what stap needs to be.

Just my thoughts - if you were wondering... ;)

miked



David Smith wrote:
David Wilder wrote:
Frank Ch. Eigler wrote:

"Ken Robson" <ken@odtv.com> writes:



[...] To me it is valid to install minus the debuginfo files on
almost all Production hosts. I am experimenting with developing my
scripts off box with my cache directory set to an exported read-only
NFS share which is then mounted as the module cache directory on my
Production boxes [...]

More than that - on such production boxes, you will need to install only the "staprun" (formerly "stapd") binary, now separated into a systemtap-runtime RPM. For the moment though please be careful with building probes for mismatching machines: the module address tables are not yet fully adaptive.

- FChE


The cached debuginfo is a really cool concept.

You got a bit confused here. The debuginfo isn't cached, the systemtap compiled modules are cached.


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.



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