Re: [RFC] Framework for easy distribution of SystemTap scripts.

[Ahmed Taha <linuxmails.lists@gmail.com>]

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 ?

Thanks, --Ahmed



On Feb 28, 2010, at 3:58, Anithra P Janakiraman <anithra@linux.vnet.ibm.com 
 > 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: <package_name> [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.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
> <distribution-fw.tgz>