Free process that consists software for linux

Process Viewer is a small utility similar to top which displays all the processes on a linux system. Its written using the FOX Toolkit.

Process Viewer is licensed under the GNU General Public License

bibEC Process Card is a multiple gateway credit card payment processor.
This class is meant to process credit card payments via one of multiple payment gateways that are supported.
Currently the class supports the following payment gateways: Plug and Pay, Authorize.net, ViaKlix, and paynet . Changing between payment gateways is mostly a matter of changing the class constructor parameter.
The class provides a payment gateway independent API with functions for:
- Logging the payment activity
- Set the payment gateway authentication credentials
- Set the paying customer details
- Set the ship to details
- Set the credit card details
- Set the valuta
- Specify the order details
- Submit the payment processing request and retrieving the results
The payment submission is done securely when possible using PHP SSL socket connections or the Curl extension for PHP or the Curl command line.

The Monitor application, which consists of 2 parts, a MonitorServer (linux daemon) and a MonitorClient (java gui), will enable the user to monitor and log server process, memory, network and cpu information of multiple servers at a time.

The MonitorClient part is written in Java and is able to connect to one or more Servers that are running the MonitorServer part of the Monitor application.

The client will poll the servers at user specified intervals and will provide a graphical representation of the recources (mem, cpu, nic and process information) of one server at a time.

In addition the MonitorClient is able to log the information of all the servers, each server in a different logfile in a coprehesive CSV format.

The MonitorServer is a seperate application written in C++ and linked to omniORB4 to minimize the load it imposes on the server that is beeing monitored. When the MonitorServer is not beeing polled by a MonitorClient it sits idle.

The client will of course run on any platform that supports Java, but the server currently only supports Linux, kernels 2.2, 2.4, 2.6 and possibly (not tested) 2.0 and >2.6.

Bootchart is a software for performance analysis and visualization of the GNU/Linux boot process. Resource utilization and process information are collected during the boot process and can later be displayed in a PNG, SVG or EPS-encoded chart.

The boot process is modified to start the boot logger (/sbin/bootchartd) instead of /sbin/init. The boot logger will run in background and collect information from the proc file system (/proc/[PID]/stat, /proc/stat and /proc/diskstats).

The statistics are logged to a virtual memory file system (tmpfs). Once the boot process completes (denoted by the existence of specific processes), the log files are packaged to /var/log/bootchart.tgz.

The log package can later be processed using a Java application which builds the process tree and renders a performance chart. The chart may then be analyzed to examine process dependency and overall resource utilization. A renderer web form is also available on the project web site.

The chart can then be analyzed to examine process dependency and overall resource utilization.

Runing:

1. Install bootchartd and the bootchart renderer. See INSTALL for details.

2. Modify your boot loader (GRUB/LILO) if necessary. Alternatively, change the kernel command line interactively upon reboot.
Reboot.

3. Verify that /var/log/bootchart.tgz was created and contains the log files.

4. Render the chart by running:

$ java -jar bootchart.jar

Alternatively (if no Java Development Kit is installed to build the JAR package), the web renderer may be used.

To use the web renderer from a script, run:
curl --form format=svg --form log=@/var/log/bootchart.tgz
http://bootchart.klika.si:8080/bootchart/render > bootchart.svgz

(optionally replacing the svg/bootchart.svgz pair with png/bootchart.png or eps/bootchart.eps.gz)

5. View the generated image and analyze the chart.
SVG images may be viewed using any of the following programs:
- rsvg-view (librsvg; GNOME)
- svgdisplay (ksvg; KDE)
- Gimp (using the gimp-svg plugin)
- Inkscape
- Squiggle (Batik; http://xml.apache.org/batik/)

To get help for additional options, run:

$ java -jar bootchart -h

How it works:

Logger Startup

The boot logger (/sbin/bootchartd) is run by the kernel instead of /sbin/init. This can be achieved by modifying the GRUB or LILO kernel command line, e.g.:

/boot/grub/menu.lst
[...]
title Fedora Core (2.6.10) - bootchart
root (hd0,1)
kernel /vmlinuz-2.6.10 ro root=/dev/hda1 init=/sbin/bootchartd
initrd /initrd-2.6.10.img

The installation script and RPM package will try to add the boot loader entry automatically.

The boot logger will start itself in the background and immediately run the default init process, /sbin/init. The boot process will then continue as usual.

Data Collection

Since the root partition is mounted read-only during boot, the logger needs to store data in memory, using a virtual memory file system (tmpfs).

As soon as the /proc file system is mounted — usually early in the sysinit script — the logger will start collecting output from various files:
/proc/stat system-wide CPU statistics: user, system, IO and idle times
/proc/diskstats system-wide disk statistics: disk utilization and throughput
(only available in 2.6 kernels)
/proc/[PID]/stat information about the running processes: start time, parent PID, process state, CPU usage, etc.

The contents of these files are periodically appended to corresponding log files, every 0.2 seconds by default.

The logger will try to detect the end of the boot process by looking for specific processes. For example, when in runlevel 5 (multi-user graphical mode), it will look for gdmgreeter, kdm_greet, etc. As soon as one of these processes is found running, the logger will stop collecting data, package the log files and store them to /var/log/bootchart.tgz.

Optional Process Accounting

In most cases, the output from /proc/[PID]/stat files suffices to recreate the process tree. It is possible however, that a short-lived process will not get picked up by the logger. If that process also forks new processes, the logger will lack dependency information for these "orphaned" processes — meaning that they might get incorrectly grouped by the chart renderer.

When truly accurate dependency information is required, process accounting may be utilized. If configured, the kernel will keep a log file with detailed information about processes. BSD process accounting v3 includes information about the process PID and parent PID (PPID) — effectively enabling an accurate reconstruction of the process tree.

To enable process accounting, the kernel needs to be configured to include CONFIG_BSD_PROCESS_ACCT_V3, under:

[ ] General setup
[ ] BSD Process Accounting
[ ] BSD Process Accounting version 3 file format

The GNU accounting utilities (package psacct or acct) also need to be installed. The boot logger will use the accton command to enable process accounting; it will include the accounting log in the tarball.

Visualization

The log tarball is later passed to the Java application for parsing and rendering the data. The CPU and disk statistics are used to render stacked area and line charts. The process information is used to create a Gantt chart showing process dependency, states and CPU usage.

A typical boot sequence consists of several hundred processes. Since it is difficult to visualize such amount of data in a comprehensible way, tree pruning is utilized. Idle background processes and short-lived processes are removed. Similar processes running in parallel are also merged together.

Finally, the performance and dependency charts are renderer as a single image in either PNG, SVG or EPS format.

XML::Records is a Perl module for perlish record-oriented interface to XML.

SYNOPSIS

use XML::Records;
my $p=XML::Records->new(data.lst);
$p->set_records(credit,debit);
my ($t,$r)
while ( (($t,$r)=$p->get_record()) && $t) {
my $amt=$r->{Amount};
if ($t eq debit) {
...
}
}

XML::Records provides a single interface for processing XML data on a stream-oriented, tree-oriented, or record-oriented basis. A subclass of XML::TokeParser, it adds methods to read "records" and tree fragments from XML documents.

In many documents, the immediate children of the root element form a sequence of identically-named and independent elements such as log entries, transactions, etc., each of which consists of "field" child elements or attributes. You can access each such "record" as a simple Perl hash.

You can also read any element and its children into a lightweight tree implemented as a Perl hash, or feed the contents of any element and its children into a SAX handler (making it possible to process "records" with modules like XML::DOM or XML::XPath).

KinoSearch::Docs::FileFormat Perl module contains an overview of invindex file format.

It is not necessary to understand the guts of the Lucene-derived "invindex" file format in order to use KinoSearch, but it may be helpful if you are interested in tweaking for high performance, exotic usage, or debugging and development.
On a file system, all the files in an invindex exist in one, flat directory.

Conceptually, the files have a hierarchical relationship: an invindex is made up of "segments", each of which is an independent inverted index, and each segment is made up of several subsections.

[invindex]--|
|-"segments" file
|
|-[segments]------|
|--[seg _0]--|
| |--[postings]
| |--[stored fields]
| |--[deletions]
|
|--[seg _1]--|
| |--[postings]
| |--[stored fields]
| |--[deletions]
|
|--[ ... ]---|

The "segments" file keeps a list of the segments that make up an invindex. When a new segment is being written, KinoSearch may put files into the directory, but until the segments file is updated, a Searcher reading the index wont know about them.

Each segment is an independent inverted index. All the files which belong to a given segment share a common prefix which consists of an underscore followed by 1 or more decimal digits: _0, _67, _1058. A fully optimized index has only a single segment.

In theory there are many files which make up each segment. However, when you look inside an invindex not in the process of being updated, youll probably see only the segments file and files with either a .cfs or .del extension. The .cfs file, a "compound" file which is consolidated when a segment is finalized, "contains" all the other per-segment files.

Segments are written once, and with the exception of the deletions file, are never modified once written. They are deleted when their data is written to new segments during the process of optimization.