From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22412 invoked by alias); 1 Mar 2010 06:41:22 -0000 Received: (qmail 22392 invoked by uid 22791); 1 Mar 2010 06:41:20 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Mar 2010 06:41:14 +0000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id o216f8W0018188 for ; Mon, 1 Mar 2010 17:41:08 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o216fBtp1556722 for ; Mon, 1 Mar 2010 17:41:11 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o216fACZ028950 for ; Mon, 1 Mar 2010 17:41:11 +1100 Received: from apj.in.ibm.com ([9.124.35.92]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o216f8JZ028914; Mon, 1 Mar 2010 17:41:09 +1100 Message-ID: <4B8B6183.3010705@linux.vnet.ibm.com> Date: Mon, 01 Mar 2010 06:41:00 -0000 From: Anithra P Janakiraman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Ahmed Taha CC: "systemtap@sourceware.org" Subject: Re: [RFC] Framework for easy distribution of SystemTap scripts. References: <4B1FE14D.5070307@linux.vnet.ibm.com> <4B685611.5090402@linux.vnet.ibm.com> <4B7C30CF.6070808@linux.vnet.ibm.com> <4B8A3E2B.1030706@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00551.txt.bz2 On 03/01/2010 01:56 AM, Ahmed Taha wrote: > Hi, > > Please help me understand the jump that had just happened. What you are > saying is that to troubleshoot an abnormality or a kernel hanging or a > softlock due to a random process or a stateless nfsv4 hanging-kernel, I > do NOT have to install a release-specific systemtap rpm with its debug > info kernel, but all what I do now is to generate the systemtap rpm > customized to a certain config parameters Provided I have already > initial snapshots of systemtap runs on another machine ? > There is no change in the existing SystemTap packaging and/or distribution. This is *ONLY* for distribution of specific SystemTap scripts. This will be useful if you have SystemTap installed on another machine which has the same configuration(arch,kernel,..) as the machine you wish to troubleshoot. You can generate a custom package for the script that you wish to run using the stap-buildpkg on the machine that has SystemTap installed. The resulting 'custom package' is an executable that can be distributed to other machines that have an identical configuration(that may or may not have SystemTap installed). When the 'custom package' is invoked it would execute a pre-compiled version of the script that you had provided. Regards, Anithra > > > > On Feb 28, 2010, at 3:58, Anithra P Janakiraman > wrote: > >> Hi, >> >> Please do let me know if there are any concerns/suggestions with the >> distribution framework. >> We are thinking a man page would not be necessary as usage is trivial. >> Let me know if it is needed ((README has been included). >> >> Regards, >> Anithra. >> >> >> >> >> On 02/17/2010 11:39 PM, Anithra P Janakiraman wrote: >>> >>> Hi, >>> >>> I've attached a modified framework. The systemtap_pkg_generator now >>> generates a package that includes staprun,stapio, an install script and >>> the generated kernel module. The files are not packaged into an rpm, and >>> no installation happens. The resulting 'package' is a self-extracting >>> binary file that extracts all files to the current dir, invokes the >>> install script which in turn invokes staprun from the current dir. This >>> binary file can only be executed by root users. >>> >>> Please comment. >>> >>> Regards, >>> Anithra. >>> >>> >>> On 02/02/2010 10:12 PM, Anithra P Janakiraman wrote: >>>> Hi, >>>> >>>> I've attached a modified framework. The names of the template/config >>>> files have been changed(no change in functionality). I've attempted to >>>> keeps the names compatible with other scripts in the SystemTap package. >>>> We would like to keep the framework in a seperate directory (similar to >>>> the initscript dir) for the sake of simplicity. (called >>>> distribution-framework or distribution-fw?) >>>> >>>> The directory would contain the following >>>> template.specfile >>>> template.install >>>> template.binextractor >>>> config.rpmoptions >>>> systemtap-rpm-generator (This is the executable script) >>>> README >>>> >>>> >>>> Let me know if any changes are needed (names of files/directory or >>>> contents). If there is any naming convention that i should adhere to >>>> please let me know. If there are no concerns, or suggestions i would >>>> like to go ahead and commit the framework. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Anithra >>>> >>>> >>>> >>>> On 12/09/2009 11:11 PM, Anithra P Janakiraman wrote: >>>>> Hi all, >>>>> >>>>> We've been looking at a simplified distribution framework for >>>>> SystemTap >>>>> scripts that : >>>>> 1. packages a set of systemtap scripts and dependent >>>>> tapsets in a form that circumvents , as much as possible the need for >>>>> external dependencies(like kernel-debuginfo) >>>>> 2. installs, runs the script, post processes the output and uninstalls >>>>> out of the box >>>>> >>>>> We feel this would be especially useful in scenarios where support >>>>> admins wish to run a particular set of script(s) on a machine for >>>>> debug >>>>> or monitoring purposes. I'm attaching an rpm-based framework that does >>>>> the following: >>>>> 1. Compiles a set of scripts into a set of kernel modules >>>>> on another machine of identical architecture that has SystemTap >>>>> installed and running >>>>> 2. Creates an rpm on the fly that would consist of >>>>> i) kernel modules ii) staprun & stapio taken from the >>>>> systemtap-runtime >>>>> package in the machine that has SystemTap installed, iii) post >>>>> processing script to process the output(optional) >>>>> 3. Bundles the above >>>>> rpm with an install script that has options to i) install the rpm ii) >>>>> run / stop iii) uninstall iv) all of the above. >>>>> 4 . The rpm and the >>>>> install script are packaged into a self-extracting binary that would >>>>> extract itself and execute 1 of the four steps above. >>>>> >>>>> The framework would mainly consist of >>>>> 1. rpm-generating script >>>>> (rpm-generator.sh) that does all of the above >>>>> 2. spec file template that >>>>> will be modified by the rpm-generator on the fly and used to build the >>>>> rpm >>>>> 3. install script template that will be modified by the >>>>> rpm-generator and bundled with the rpm >>>>> 4. Configuration file - that >>>>> would specify the location of the scripts/tapsets >>>>> >>>>> The rpm is packaged as a self extracting binary for ease of use. When >>>>> the binary is executed it extracts the rpm package and based on the >>>>> parameters provided either installs/runs/uninstalls the rpm. Help >>>>> detailing the available options are also provided >>>>> >>>>> USAGE: [options] [parameters] >>>>> >>>>> Options: >>>>> * --install -i Install the tapset rpm. >>>>> * --run -r Runs the scripts >>>>> for n minutes where n can be passed as a parameter. o The default >>>>> value >>>>> is 10 minutes. Post processing is performed after the script >>>>> completes. >>>>> * --start -s Invokes the script as a background process. >>>>> * --stop -x Stops the script and performs post processing. >>>>> * --uninstall -u Stops the script if running and uninstalls the rpm. >>>>> * --all Installs the rpm, runs the scrip, processes the output and >>>>> uninstalls the rpm. >>>>> * --help Displays this usage text. >>>>> >>>>> Parameters: >>>>> >>>>> * time=[x] x is in minutes. Runs the script for x minutes. valid for >>>>> --run(-r) o --start(-s) or --all(-a) options only >>>>> >>>>> >>>>> >>>>> One disadvantage of the above framework is that the end binary that is >>>>> created is tied to a particular kernel version/architecture. >>>>> However the >>>>> users now need not install systemtap, debuginfo and need not even be >>>>> familiar with SystemTap. This should help users and admins who wish to >>>>> run a set of scripts to solve a specific problem(maybe on a customer's >>>>> machine). >>>>> >>>>> Please comment, >>>>> >>>>> Regards, >>>>> Anithra. >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >>