From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13336 invoked by alias); 4 Feb 2010 09:17:40 -0000 Received: (qmail 13324 invoked by uid 22791); 4 Feb 2010 09:17:39 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Feb 2010 09:17:33 +0000 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by e28smtp08.in.ibm.com (8.14.3/8.13.1) with ESMTP id o148dn16005859 for ; Thu, 4 Feb 2010 14:09:49 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o149HSCu2269234 for ; Thu, 4 Feb 2010 14:47:29 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o149HSTK015851 for ; Thu, 4 Feb 2010 20:17:28 +1100 Received: from [9.124.35.34] ([9.124.35.34]) by d28av05.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o149HSRp015848; Thu, 4 Feb 2010 20:17:28 +1100 Message-ID: <4B6A90A8.10207@linux.vnet.ibm.com> Date: Thu, 04 Feb 2010 09:17:00 -0000 From: Prerna Saxena User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: systemtap@sourceware.org CC: "Frank Ch. Eigler" , Anithra P Janakiraman Subject: Re: [RFC] Framework for easy distribution of SystemTap scripts. References: <4B1FE14D.5070307@linux.vnet.ibm.com> <4B685611.5090402@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/msg00320.txt.bz2 On 02/03/2010 01:57 AM, Frank Ch. Eigler wrote: > > anithra wrote: > >>> 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. > > It seems odd to have the file created by the framework-script to both > manage installation as well as execution of the compiled systemtap > materials. Why install if it can be run directly? If installed, how > else to execute the systemtap module except via this file? > > Perhaps the stap-buildrpm widget should create a plain rpm that is > self-explanatory to install, within which a /usr/bin/FOO shell script > manage the execution of the script. > > It may be nice if stap-buildrpm interfaced with stap-initscripts, so > that rpms produced this way were easily activatable from that scheme. > > > - FChE A little background on this framework might be of help in understanding the design goals for it. The idea was to build small diagnostic utilities based on systemtap that could be deployed on external systems (which may or may not have systemtap and dependencies like debuginfo installed). These could be used to glean specific information about the system. Systemtap-generated kernel modules, along with systemtap runtime looked like a good mechanism to distribute such utilities. We decided to package the precompiled kernel modules along with systemtap runtime binaries in an rpm. Also, we thought that the rpm installation ; systemtap module insertion, and data filtering and logging ought to be transparent to the support admin who is running this -- so we packaged the rpm alongwith a wrapper shell script that automates all these steps for the user. This was bundled in a self-extracting archive for simplicity of use. This framework can be employed to build such diagnostic utilities on the fly. The 'install' option in the shell script merely installs the rpm, ie, it copies the systemtap kernel module and runtime in a specified location. The 'uninstall' option removes systemtap kernel module and other files installed by the rpm. The 'run' option launches staprun to insert the systemtap generated kernel module, employs an optional post-processing script to filter the data logged, stores logs in a pre-specifed log file, and causes the systemtap kernel module to be clean-removed. The 'all' option does all these steps in order. Interfacing with initscripts is a good add-on, but the primary purpose was to deploy such diagnostics on installations that lack systemtap and dependencies -- it was meant to be self-sufficient. The framework can be enhanced if it is found useful to begin with :-) Regards, -- Prerna Saxena as possible Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India