Server Usage

Starting and Stopping the Server

If Running as Linux Daemon

When the YarraServer has been installed as daemon (recommended and described here), the YarraServer can be started using a terminal shell (as user yarraserver) and typing:

The server is now running in the background. To stop the server, type:

The server will shut down after completing the active task (if existing).

If Running as Command-Shell Application

When running YarraServer as command-shell application (only recommended for testing purpose), the YarraServer can be started using a terminal shell (as user yarraserver) and typing:

The server is now running in the background. To stop the server, type:

The server will shut down after completing the active task (if existing).

 

Monitoring the Server Activity

To test if the server is currently active, write the following command:

To check if the server is idle or processing a task, use the following command:

To view the output of the currently running reconstruction task, use the command:

 

Terminating an Unresponsive Task

If reconstruction modules become unresponsive, termination of the YarraServer can be enforced by typing the command:

This will terminate module and shutdown the YarraServer immediately. If the server is running as daemon, it will be automatically restarted and will continue with the next reconstruction task (when running it as command-shell application, the server needs to be restarted manually).

 

Note
More convenient monitoring (and controlling) of the server is possible by installing the Yarra WebGUI, as described here.

 

Output Directories

Reconstruction tasks that are  submitted by the Yarra clients are first placed in the queue directory. The server then selects one task an moves the files into the work directory. If a reconstruction problem should occur and the processing was not successful, the files of the failed task will be moved to a subfolder of the directory fail (thus, data from unsuccessful tasks will never be lost). If a reconstruction mode defines that also data from successful reconstructions should be kept (e.g., to archive the data for later reprocessing), the files form the task will be moved to a subfolder of the directory finished. To avoid that a lot of cases pile up in this directory, it is recommended to move older files to a long-term storage directory, e.g. using an automated cron job.

 

Logfiles

The YarraServer has two logging mechanisms: A server log, which contains coarse information about what tasks were processed and when problems occurred, and an individual task log, which contains detailed information about each task, including all output that the modules created. This file can be very helpful when investigating reconstruction problems or crashes.

All log files are stored in the subdirectory log. The server log has the fixed file name yarra.log. If the log file gets too large, it will be archived (by adding a time stamp to the file name) and a clean file will be created. The task log is named according to the task ID, i.e. the name of the submitted file, with the extension “.log”. If a task is submitted and a log file with this name already exists, a time stamp will be appended. Note: All notification emails show the task ID at the bottom of the mail, which makes it easy to identify the log file. The file name of the log file of the currently active task can be obtained by calling:

 

Notification Emails

The YarraServer will send notification emails on completion or failure of tasks (prerequisites are that the sendmail package is installed and that notifications are enabled in the server configuration). Completion notifications will be sent to a) receivers listed in the Yarra client during submission and b) receivers listed in the reconstruction-mode file. Failure notifications will be, in addition, also sent to those receivers listed in the server configuration file under Options/ErrorMail.

Completion mails are indicated by a purple color bar whereas failure message appear in red color. Failure emails contain the task log in the attachment. Note: The task log may contain PHI-relevant information, such as the patient name, and should never be forwarded to external email addresses.

notifications