Chapter 7. How to run

Table of Contents

7.1. Environment
7.2. Server
7.3. Job Manager
7.4. PROOF workers
7.5. PROOF Connection String
7.6. Analysis
7.7. How to shut down PoD
7.8. if something is wrong

7.1. Environment

In order to enable PoD's environment you need to source the PoD_env.sh script. The script is located in the directory where you installed PoD.

cd [POD INSTALLATION]
source PoD_env.sh

Also don't forget, before starting PoD the ROOT should be in the PATH as well.

7.2. Server

[Note]local and remote PoD servers

There are two ways you can use PoD: as a local server and a remote one. On how to use a remote PoD server please check the pod-remote(1) command.

Further in this chapter are the instructions on how to use a local PoD server.

Use the pod-server command to start/stop/status PoD servers.

pod-server start

7.3. Job Manager

The next step is to submit remote PoD workers using PoD's job manager. These PoD workers will automatically setup your PROOF workers on remote hosts. Starting from version 2.0.7 the PoD project supports plug-ins. To submit remote jobs job manager plug-ins are used. That means PoD could be used on different resources like Grid, Cloud, RMS or just simple machines with only an ssh access on them. It also possible to use a combination of plug-ins to get PROOF workers on Grid worker nodes and local batch machines in the same time.

In order to setup a dynamic PROOF cluster on RMS such as gLite, LSF, PBS, Condor, LoadLeveler or (Oracle/Sun)GridEngine, use the pod-submit command.

The following simple example illustrates a submission of 15 workers to an LSF farm using the "proof" queue.

pod-submit -r lsf -q proof -n 15

Use PoD user defaults to tune individual settings of plug-ins: gLite, LSF, PBS, Condor, LoadLeveler or (Oracle/Sun)GridEngine.

If there is no RMS available, you can use PoD's SSH plug-in. Please see Chapter 8, SSH plug-in for more details.

7.4. PROOF workers

As soon as a single job reaches remote worker node (WN), it tries to connect to PoD server to transfer information about itself and environment of WN. When negotiations are done and PoD server accepts WNs, it became a normal PROOF Worker for the user.

It is not required to wait until all requested workers will be connected. Users could start analysis after reasonable number of workers are on-line, even after the first connected worker one could start the analysis. When other workers arrive, the ROOT (PROOF) session must be restarted in order to reconnect to the newly arrived workers.

[Tip]Tip

PoD supports reconnection. That means if your analysis has a bug or a root session crashed you don't need to resubmit PoD jobs. You just need to close current root session, open it again. PoD will manage reconnection with its worker nodes automatically. Worker nodes will be on-line until the pod-agent service is on-line or until s Grid and/or batch queue time is over.

Use the pod-info command to find out a number

pod-info -n

or to list

pod-info -l

available PROOF workers.

The pod-info -l command can be also used to check, whether a direct connection (preferable) or a packet forwarded connection is used to connect PROOF server to workers. PoD y default automatically chooses the type of connections.

If PoD server can't directly connect to its workers on xpd port, then the packet forwarded connection is used. With this type of connection, some PROOF functions will be limited. For example, workers can't be used as parallel sub-mergers, since a direct connection between workers will be required. We therefore recommend to open an xpd port range (PoD user defaults: worker.xproof_ports_range_(min/max)) for incoming connections on the worker nodes. This will help PoD to set up the most efficient type of connection.

7.5. PROOF Connection String

PROOF connection string - is an URL which is used as a parameter to the TProof::Open method. This URL actually contains an address of PROOF master, its host and port.

Every time PoD is restarted it uses its automatic port mapping machinery to assign TCP ports to xproofd and other daemons. That means, a PROOF master port can always be a different one. In order always get the actual port and even the whole PROOF connection string the pod-info(1) can be used.

For an example analysis, please see Chapter 9, How to test.

7.6. Analysis

Now when your remote PROOF workers (PoD workers) are on-line, you can process you ROOT/PROOF analysis normally, if it would be a usual PROOF session.

For an example analysis, please see Chapter 9, How to test.

7.7. How to shut down PoD

In order to shut down PoD, a PoD server should be stopped.

pod-server stop

7.8. if something is wrong

If something goes wrong, something doesn't work as expected, please, check the log files first.

Table 7.1. PoD log files

NameLocationDescription
pod-agent.server.logserver.logfile_dir/pod-agent.server.logThis file contains a log messages of the pod-agent, which runs on the user interface.
xpd.logserver.logfile_dir/PoDServerThis is an XROOTD log file.


All job manager plug-ins are also able to deliver the logs from worker nodes. Please refer to the plug-ins configuration for more details.

If you still can't resolve the issue or have something to report, use Chapter 13, Support.