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: [RFC] Framework for easy distribution of SystemTap scripts.


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 <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>


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