Bases: nepi.execution.resource.ResourceManager
| Parameters: |
|
|---|
Note
A LinuxApplication RM represents a process that can be executed in a remote Linux host using SSH.
The LinuxApplication RM takes care of uploadin sources and any files needed to run the experiment, to the remote host. It also allows to provide source compilation (build) and installation instructions, and takes care of automating the sources build and installation tasks for the user.
It is important to note that files uploaded to the remote host have two possible scopes: single-experiment or multi-experiment. Single experiment files are those that will not be re-used by other experiments. Multi-experiment files are those that will. Sources and shared files are always made available to all experiments.
Directory structure:
The directory structure used by LinuxApplication RM at the Linux host is the following:
${LIB} |- /lib –> Base directory for libraries ${BIN} |- /bin –> Base directory for binary files ${SRC} |- /src –> Base directory for sources ${SHARE} |- /share –> Base directory for other files
${RUN_HOME} |- /<run-id> –> Base directory for run specific
Returns True if the command needs to be executed in foreground. This means that command will be executed using ‘execute’ instead of ‘run’ (‘run’ executes a command in background and detached from the terminal)
When using X11 forwarding option, the command can not run in background and detached from a terminal, since we need to keep the terminal attached to interact with it.
Error codes that the rexitcode function can return if unable to check the exit code of a spawned process
Bases: nepi.execution.resource.ResourceManager
| Parameters: |
|
|---|
Note
There are different ways in which commands can be executed using the LinuxNode interface (i.e. ‘execute’ - blocking and non blocking, ‘run’, ‘run_and_wait’).
Brief explanation:
‘execute’ (blocking mode) :
HOW IT WORKS: ‘execute’, forks a process and run the command, synchronously, attached to the terminal, in foreground. The execute method will block until the command returns the result on ‘out’, ‘err’ (so until it finishes executing).
USAGE: short-lived commands that must be executed attached to a terminal and in foreground, for which it IS necessary to block until the command has finished (e.g. if you want to run ‘ls’ or ‘cat’).
‘execute’ (NON blocking mode - blocking = False) :
HOW IT WORKS: Same as before, except that execute method will return immediately (even if command still running).
USAGE: long-lived commands that must be executed attached to a terminal and in foreground, but for which it is not necessary to block until the command has finished. (e.g. start an application using X11 forwarding)
‘run’ :
HOW IT WORKS: Connects to the host ( using SSH if remote) and launches the command in background, detached from any terminal (daemonized), and returns. The command continues to run remotely, but since it is detached from the terminal, its pipes (stdin, stdout, stderr) can’t be redirected to the console (as normal non detached processes would), and so they are explicitly redirected to files. The pidfile is created as part of the process of launching the command. The pidfile holds the pid and ppid of the process forked in background, so later on it is possible to check whether the command is still running.
USAGE: long-lived commands that can run detached in background, for which it is NOT necessary to block (wait) until the command has finished. (e.g. start an application that is not using X11 forwarding. It can run detached and remotely in background)
‘run_and_wait’ :
HOW IT WORKS: Similar to ‘run’ except that it ‘blocks’ until the command has finished execution. It also checks whether errors occurred during runtime by reading the exitcode file, which contains the exit code of the command that was run (checking stderr only is not always reliable since many commands throw debugging info to stderr and the only way to automatically know whether an error really happened is to check the process exit code).
Another difference with respect to ‘run’, is that instead of directly executing the command as a bash command line, it uploads the command to a bash script and runs the script. This allows to use the bash script to debug errors, since it remains at the remote host and can be run manually to reproduce the error.
USAGE: medium-lived commands that can run detached in background, for which it IS necessary to block (wait) until the command has finished. (e.g. Package installation, source compilation, file download, etc)
Checks whether errors occurred while running a command. It first checks the exit code for the command, and only if the exit code is an error one it returns the error output.
Cleans all experiment related files in the Linux host. It preserves NEPI files and folders that have a multi experiment scope.
Notice that this invocation will block until the execution finishes. If this is not the desired behavior, use ‘run’ instead.
Get the exit code of an application. Returns an integer value with the exit code
Removes files that already exist in the Linux host from src list
either as an inline command (i.e. export PYTHONPATH=src/..; export LALAL= ..;python script.py) or as a bash script (i.e. export PYTHONPATH=src/..
export LALA=..
)
Install packages in the Linux host.
‘home’ is the directory to upload the package installation script. ‘run_home’ is the directory from where to execute the script.
Paths is either a single remote directory path to create, or a list of directories to create.
Uninstall packages from the Linux host.
‘home’ is the directory to upload the package un-installation script. ‘run_home’ is the directory from where to execute the script.
Paths is either a single remote directory path to delete, or a list of directories to delete.
Uploads the ‘command’ to a bash script in the host. Then runs the script detached in background in the host, and busy-waites until the script finishes executing.
Copy content to destination
text src is text input, it must be stored into a temp file before uploading
Saves the command as a bash script file in the remote host, and forces to save the exit code of the command execution to the ecodefile
Bases: nepi.resources.linux.application.LinuxApplication
Bases: nepi.resources.linux.application.LinuxApplication
Uses the hpcbench udptest tool to gather UDP measurements. Measurements require two ends, a server and a client RM.