pod-remote — Using this command users can start/stop/restart remote PoD servers. The utility can also be used to execute arbitrary commands on remote PoD servers, such as PoD job submissions.


pod-remote (1) general options (2) connection options (3) commands

(1) [-h, --help] [-v, --version] [-d, --debug] [-c file, --config=file]
(2) [--remote arg] [--ssh-opt arg] [--ssh-open-domain arg] [--env-local arg] [--env-remote arg]
(3) [[--start] | [--stop] | [--restart] | [--command cmd]]


In order to use pod-remote BOOST 1.41.0 (or higher) is required.


The current implementation requires users to have a public key access (password less) to destination remote hosts (PoD servers).

The pod-remote command offers a possibility to fully control remote PoD servers. A PROOF cluster created using pod-remote is accessed via SSH tunnels, which are automatically managed by pod-remote.

Using pod-remote it is possible to start/restart/stop remote PoD servers. It is also possible to submit PoD jobs from remote PoD servers in order to set remote PROOF clusters up.

Most importantly, pod-remote automatically creates and handles SSH tunnels for remote PoD servers, so that these servers can be used only via SSH connection - outside of a firewall. Tunnels stay alive until remote server is alive or you restart/stop pod-remote. The pod-remote command creates a background daemon, which regularly checks the status of the remote PoD server and manages tunnels. Another important feature of pod-remote is its integration into PoD, see the section called “Examples”.

The pod-remote command remembers all connection options values and next time you want to use pod-remote with the same server, you can omit these arguments and just call: pod-remote --start/stop/restart without --remote and --env. The command will always use the latest given settings. If you want to change the server, just provide new arguments values.

The pod-remote utility exits 0 on success, and >0 if an error occurs.


-h, --help

Produce help message.

-v, --version

Version information.

-d, --debug

Show debug messages. This option enables a debug mode and helps in some cases to understand what is going wrong.

-c file, --config=file

Specify an options file with the pod-remote command line options.

--remote arg

A connection string including a remote PoD location. For example: loginname@serverhostname:/PoD/location/pathname

--ssh-opt arg

If needed, users can provide additional SSH options, which will be used by pod-remote in all SSH communications.

--ssh-open-domain arg

The name of a third party machine open to the outside world and from which direct connections to the server are possible. The optional argument, can be used when PoD server machine is not directly accessible from outside via SSH.

--env-local arg

A full path to a local environment script, which will be executed on the remote-end before PoD starts the server. This is needed in order to get working environment on the remote host before PoD server can be started. In most of the case you would need to source proper ROOT environment. You can, of course, also set some other env. variables in the script, if needed.

--env-remote arg

The same as --env-local, but the script is located on the remote machine and will be sourced there.


Start remote PoD server.


Stop remote PoD server.


Restart remote PoD server.


Execute arbitrary commands.


Example 10.9. Using remote PoD server

Let's say, I have two machines A and B.

A - is my laptop, for example.
B - is a machine (host: lxg0527) standing somewhere at my work place.
    From this machine I can submit jobs to my batch system (LSF, for example) 
    or use it as a server for PoD SSH plug-in.

On both machines I have PoD installed.

All the following commands I issue from my laptop (machine A).

Start the remote PoD server:

pod-remote --start \
    --remote \
    --env-local ../

The command above starts a remote PoD server on the host under the user manafov and uses PoD installed in the /misc/manafov/PoD/3.5.75.gbecd4 directory. To initialize the proper environment on the remote host the ../ script is used.

If everything is OK and remote server is started, pod-remote will create and manage special SSH tunnels from machine A to B. So, the whole PoD communication and PROOF requests will go via these tunnels.

To set our remote PROOF cluster up, now we need to submit PoD jobs from the remote Server (in case of RMS plug-ins):

pod-remote --command "pod-submit -r lsf -n 50 -q my_lsf_queue"

or in case of the SSH plug-in

pod-remote --command "pod-ssh -c pod_ssh.cfg submit"

Using --command, you can execute any command vie SSH on the remote server.

Now, you can just use pod-info(1) as usual, as if everything would run locally:

pod-info -s
pod-info -c
pod-info -n

The pod-info automatically detects that there is a pod-remote-managed server and will gather the information directly from it via the SSH tunnels. It means, of course, that to connect from your local machine to your remote PoD/PROOF cluster you need just to use:

TProof::Open(gSystem->GetFromPipe("pod-info -c"));

To stop the remote PoD server use:

pod-remote --stop

To start the same server again use the following command. Note missing --remote. You don't need it. The command remembers your last valid settings.

pod-remote --start

To restart the server:

pod-remote --restart