Installation

This chapter describes the recommended path for installing RTC Toolkit on a single-host ELT Development Environment. The happy path uses the released RPM packages and consists of the following steps:

  1. Bootstrap and install the supported ELT Development Environment.

  2. Install RTC Toolkit and its dependencies.

  3. Configure the user account and runtime environment.

  4. Configure and start the required CII, Consul, and Nomad services.

  5. Verify the installation.

Optional sections describe:

  • How to configure the monitoring services InfluxDB, Telegraf, and Grafana. These services are useful for observing component and state-machine metrics, troubleshooting, and performance analysis.

  • How to install RTC Toolkit from source. This is useful when developing or modifying RTC Toolkit, testing unreleased changes, or building the documentation.

Note

In console examples, # denotes a command run as root, while $ denotes a command run as a regular user. Do not type the prompt character.

Machine Preparation

This section summarizes the machine-preparation requirements specific to RTC Toolkit.

Prerequisites

Use a physical or virtual machine running AlmaLinux 10.

Note

At least 8 GB of RAM is required when compiling RTC Toolkit from source.

ELT Development Environment

The ELT Development Environment is defined by a specific ELT Platform version. RTC Toolkit version 6.0.0 requires the ELT Platform 26 stable release, which is based on AlmaLinux 10. Each ELT Platform release provides a defined set of ELT software packages.

Run the following command as root to bootstrap the selected ELT Platform and provision the machine:

# sh <(curl https://ftp.eso.org/pub/elt/repos/GetPlatform26Stable.sh)

The provisioning process may take a considerable amount of time. The command prepares the machine as a full ELT Development Environment. Among other actions, it:

  • configures the repositories for the selected ELT Platform;

  • updates the operating-system packages;

  • creates the standard elt group and the eltdev and eltmgr users;

  • configures the system timezone as UTC;

  • installs the ELT Development Environment software packages and tools.

Note

After provisioning completes successfully, reboot the machine. This ensures that any kernel updates and system configuration changes take effect. Then log in as the eltdev user to continue the RTC Toolkit installation.

Further Information

For detailed information about provisioning and maintaining an ELT machine, refer to the ELT Linux Installation Guide.

To become familiar with the development tools available on the platform, refer to the Guide to Developing Software for the ELT.

Install RTC Toolkit and Dependencies

RTC Toolkit is distributed as RPM packages for the selected ELT Platform. Install the runtime and development packages as root:

# dnf -y install elt-rtctk elt-rtctk-devel

The packaged documentation can be installed separately:

# dnf -y install elt-rtctk-doc

The elt-rtctk-debuginfo and elt-rtctk-debugsource packages are only required for debugging RTC Toolkit itself.

Account Configuration

Configure the account that will be used to run and develop RTC Toolkit. The following examples use the eltdev account created during machine provisioning.

Lmod is used to configure the user environment. It loads modulefiles that define variables such as PATH, LD_LIBRARY_PATH, PYTHONPATH, INTROOT, and DATAROOT.

  1. Log in as the user that will use RTC Toolkit.

  2. Create the local software installation and data areas:

    $ cd "$HOME"
    $ getTemplate -d introot INTROOT
    $ getTemplate -d dataroot DATAROOT
    

    These commands create two directory trees:

    • $HOME/INTROOT is the local software installation area.

    • $HOME/DATAROOT is the local data and configuration area.

    These directories are primarily used for local development and configuration. RTC Toolkit itself remains installed from the RPM packages unless it is built from source.

  3. Create the directory for the local Persistent Configuration Repository:

    $ mkdir -p "$HOME/DATAROOT/config/persistent_repo"
    
  4. Create the user modulefile directory and the private.lua modulefile:

    $ mkdir -p "$HOME/modulefiles"
    $ vi "$HOME/modulefiles/private.lua"
    

    Add the following content:

    local introot = "/home_local/eltdev/INTROOT"
    local dataroot = "/home_local/eltdev/DATAROOT"
    
    setenv("INTROOT", introot)
    setenv("PREFIX", introot)
    setenv("DATAROOT", dataroot)
    
    load("rtctk")
    load("introot")
    
    prepend_path("CFGPATH", dataroot .. "/config/persistent_repo")
    

    Replace the values of introot and dataroot when using locations other than those shown in the example.

    Important

    Use prepend_path rather than setenv when updating CFGPATH. The variable may already contain system configuration paths that must be preserved.

  5. Optionally, configure a separate directory for human-readable log files.

    By default, human-readable logs are written to $INTROOT/logsink. To use another location, add the RTC_LOGS variable to private.lua:

    setenv("RTC_LOGS", "/data/logsink")
    

    Create the directory and give the user permission to write to it:

    # mkdir -p /data/logsink
    # chown eltdev:elt /data/logsink
    # chmod u+r,u+w,u+x /data/logsink
    
  6. Save private.lua.

    A complete example, including the optional custom log directory, is:

    local introot = "/home_local/eltdev/INTROOT"
    local dataroot = "/home_local/eltdev/DATAROOT"
    
    setenv("INTROOT", introot)
    setenv("PREFIX", introot)
    setenv("DATAROOT", dataroot)
    setenv("RTC_LOGS", "/data/logsink")
    
    load("rtctk")
    load("introot")
    
    prepend_path("CFGPATH", dataroot .. "/config/persistent_repo")
    
  7. Log out and log in again.

    A new login session is required so that $HOME/modulefiles is added to MODULEPATH and private.lua is loaded automatically.

  8. Verify the account configuration:

    $ module list
    $ echo "$INTROOT"
    $ echo "$PREFIX"
    $ echo "$DATAROOT"
    $ echo "$CFGPATH"
    

    The loaded module list should include at least private, introot, and rtctk.

    With the paths used in the example, the environment variables should include:

    INTROOT=/home_local/eltdev/INTROOT
    PREFIX=/home_local/eltdev/INTROOT
    DATAROOT=/home_local/eltdev/DATAROOT
    CFGPATH=/home_local/eltdev/DATAROOT/config/persistent_repo:/home_local/eltdev/INTROOT/resource:/usr/resource
    

Note

For more information about Lmod, refer to section 3.2, Environmental Modules System (Lmod), in the Guide to Developing Software for the ELT.

Configuration of Required Services

The single-host RTC Toolkit configuration described in this section uses services provided by CII, Consul, and Nomad:

  • CII OLDB provides configuration and runtime data services.

  • Consul provides service discovery when a consul endpoint is used.

  • Nomad starts and supervises deployed components.

The following procedure configures these services to run on the local machine.

Install the CII Service Packages

The CII service packages required by RTC Toolkit are not installed by default with the ELT Development Environment. Install them as root:

# dnf -y install \
    elt-ciisrv-postinstall \
    elt-ciisrv-srv-oldb

Configure CII

Run cii-postinstall as root to configure the CII services for a single-host development environment:

# cii-postinstall ownserver

This configuration runs the CII services on the local machine and is suitable for RTC Toolkit development, tutorials, and basic testing.

For configurations in which the CII services run on dedicated hosts, refer to the CII Services Management documentation.

Configure Consul

Consul provides service discovery and name resolution. It is required when the Service Discovery Endpoint uses the consul scheme.

For a single-host development environment, edit /etc/consul.d/consul.hcl as root and replace its contents with:

datacenter = "dc1"
data_dir = "/opt/consul"
server = true
retry_join = ["127.0.0.1"]

addresses = {
    "http"  = "127.0.0.1"
    "grpc"  = "127.0.0.1"
    "https" = "127.0.0.1"
    "dns"   = "127.0.0.1"
}

advertise_addr = "127.0.0.1"
bootstrap_expect = 1

This configuration creates a single Consul server that listens only on the local host.

Configure Nomad

Nomad is used to start and monitor RTC Toolkit components.

For a single-host development environment, edit /etc/nomad.d/nomad.hcl as root and replace its contents with:

data_dir = "/opt/nomad/data"
bind_addr = "127.0.0.1"

advertise {
    http = "127.0.0.1"
    rpc  = "127.0.0.1"
    serf = "127.0.0.1"
}

server {
    bootstrap_expect = 1
    enabled = true
}

client {
    enabled = true
    servers = ["127.0.0.1:4647"]

    options = {
        "driver.raw_exec.enable" = "1"
    }

    template = {
        "disable_file_sandbox" = true
    }

    meta {
        "node" = "hrtc-gw,srtc1"
    }
}

This configuration runs both the Nomad server and client on the local machine. The raw_exec driver allows Nomad to execute RTC Toolkit components directly on the host.

Start and Verify the Required Services

Start the services in the following order:

  1. CII OLDB

  2. Consul

  3. Nomad

CII OLDB

Start the CII OLDB services as the eltdev user:

$ cii-services start oldb

Verify their status:

$ cii-services info

The output should show the OLDB services as active and the OLDB functional checks as successful.

Note

The complete CII service set can be started with:

$ cii-services start all

The complete set consumes more CPU and memory than the minimal OLDB configuration required by RTC Toolkit.

To stop the CII services when they are no longer needed:

$ cii-services stop all

In general, the CII services can remain running while using RTC Toolkit.

Consul

Start the Consul system service:

$ systemctl start consul

Check the service status:

$ systemctl status consul

Verify that the Consul agent responds:

$ consul catalog services

To stop Consul:

$ systemctl stop consul

Nomad

Start the Nomad system service after Consul is running:

$ systemctl start nomad

Check the service status:

$ systemctl status nomad

Verify that the Nomad agent responds:

$ nomad job status

To stop Nomad:

$ systemctl stop nomad

Verify the Installation

After configuring the account and starting the required CII, Consul, and Nomad services, verify the RTC Toolkit installation as the eltdev user.

First, verify that the RTC Toolkit runtime and development RPM packages are installed:

$ rpm -q elt-rtctk elt-rtctk-devel

The command should report the installed version of both packages and should not report that either package is missing.

Verify that the user environment has been loaded:

$ module list
$ echo "$INTROOT"
$ echo "$DATAROOT"
$ echo "$CFGPATH"

The loaded module list should include at least private, introot, and rtctk. The environment variables should contain the locations configured in private.lua.

Verify that the required services are running and responding:

$ cii-services info
$ systemctl is-active consul nomad
$ consul catalog services
$ nomad job status

The CII output should show the OLDB services as active and their functional checks as successful. Both Consul and Nomad should report active. The Consul and Nomad commands should complete without a connection error.

At this point, the RTC Toolkit RPM installation and the required single-host services are ready for use.

CII Service Documentation

Consult the CII Documentation for more information about the CII service-management commands and their output.

Configuration of Optional Services

The monitoring stack is optional. RTC Toolkit can run without it, but InfluxDB, Telegraf, and Grafana provide historical metrics, runtime observability, and dashboards for troubleshooting and performance analysis.

Configure the services in the following order:

  1. InfluxDB

  2. Telegraf

  3. Grafana

Install the Monitoring Packages

RTC Toolkit version 6.0.0 has been tested with:

  • InfluxDB 3 Core 3.8.0

  • Telegraf 1.36.4

  • Grafana 12.3.1

Important

Use Grafana 12.3.1. Older Grafana versions may not support the query representation used by the RTC Toolkit dashboards.

Download the tested RPM package versions directly:

# wget https://repos.influxdata.com/rhel/10/x86_64/stable/influxdb3-core-3.8.0.x86_64.rpm
# wget https://repos.influxdata.com/rhel/10/x86_64/stable/telegraf-1.36.4-1.x86_64.rpm
# wget https://dl.grafana.com/grafana/release/12.3.1/grafana_12.3.1_20271043721_linux_amd64.rpm

Install the packages as root:

# dnf -y install ./influxdb3-core-3.8.0.x86_64.rpm
# dnf -y install ./telegraf-1.36.4-1.x86_64.rpm
# dnf -y install ./grafana_12.3.1_20271043721_linux_amd64.rpm

Note

The external package repositories may not be reachable from restricted ELT networks. In that case, download the RPM files on another machine and copy them to the ELT Development Environment.

InfluxDB

InfluxDB 3 Core stores the metrics collected by Telegraf.

RPM installations provide the configuration file /etc/influxdb3/influxdb3-core.conf. Configuration values in this file are converted into environment variables by the systemd launcher. Explicit command-line options take precedence over these values.

Choose either authenticated or unauthenticated operation before starting the service.

Authenticated Operation

InfluxDB enables authentication by default. Generate an offline administrator token file as root:

# influxdb3 create token \
    --admin \
    --offline \
    --output-file /etc/influxdb3/token.json

Configure InfluxDB to load this token by adding the following entry to /etc/influxdb3/influxdb3-core.conf:

admin-token-file = "/etc/influxdb3/token.json"

The generated JSON file contains the token that must be supplied to InfluxDB clients, Telegraf, and the Grafana data source.

Unauthenticated Operation

For an isolated single-host development environment, authentication can be disabled by adding the following entry to /etc/influxdb3/influxdb3-core.conf:

without-auth = "true"

Warning

Do not disable authentication on a machine that is accessible from an untrusted network.

Start InfluxDB

Start the service:

# systemctl start influxdb3-core

Verify that it is running:

# systemctl status influxdb3-core

Create the Database

InfluxDB can create a database automatically when data is first written. However, an implicitly created database uses infinite retention.

A retention period can only be selected when the database is created. For example, create a database with a 30-day retention period:

$ influxdb3 create database \
    --retention-period 30d \
    DATABASE_NAME

When authentication is enabled, provide the administrator token:

$ influxdb3 create database \
    --token <INFLUXDB_ADMIN_TOKEN> \
    --retention-period 30d \
    DATABASE_NAME

Note

The minimum practical retention period is one hour. An existing retention period cannot be changed; create a new database when a different retention period is required.

For additional configuration options, refer to the InfluxDB configuration documentation.

Telegraf

Telegraf receives RTC Toolkit metrics and writes them to InfluxDB.

Configure the agent using /etc/telegraf/telegraf.conf. The following configuration provides a working single-host example:

# Configuration for telegraf agent
[agent]
  interval = "10s"              ## default data collection interval for all inputs
  round_interval = true         ## if interval="10s" then always collect on :00, :10, :20, etc.
  metric_batch_size = 1000      ## this controls the size of writes that Telegraf sends to output plugins
  metric_buffer_limit = 10000   ## for failed writes, telegraf will cache metric_buffer_limit metrics for each output, and will flush this buffer on a successful write
  collection_jitter = "0s"      ## collection jitter is used to jitter the collection by a random amount. Each plugin will sleep for a random time within jitter before collecting
  flush_interval = "10s"        ## default flushing interval for all outputs. Maximum flush_interval will be flush_interval + flush_jitter
  flush_jitter = "0s"           ## jitter the flush interval by a random amount. This is primarily to avoid large write spikes for users running a large number of telegraf instances.
  precision = "1ns"

  ## Logging configuration:
  debug = true                  ## Run telegraf with debug log messages.
  quiet = false                 ## Run telegraf in quiet mode (error log messages only).
  logfile = ""                  ## Specify the log file name. The empty string means to log to stderr.

  hostname = ""                 ## Override default hostname, if empty use os.Hostname()
  omit_hostname = false         ## If set to true, do no set the "host" tag in the telegraf agent.
  skip_processors_after_aggregators = true

## this part is for the connection of RTC components
[[inputs.socket_listener]]
  service_address = "udp://:8081"
  data_format = "influx"

## this part is for executing shell script
[[inputs.exec]]
  commands = [
    "bash -c 'echo \"system,host=$(hostname) kernel_version=\\\"$(uname -r)\\\",distro=\\\"${PRETTY_NAME:-undefined}\\\",elt_release=\\\"${ELT_RELEASE:-undefined}\\\"\"'"
  ]
  data_format = "influx"
  interval = "24h"

## this part is for collecting metrics from the OS
[[inputs.cpu]]
  percpu = true            ## whether to report per-cpu stats or not
  totalcpu = true          ## whether to report total system cpu stats or not
  collect_cpu_time = false ## if true, collect raw CPU time metrics
  report_active = false    ## if true, compute and report the sum of all non-idle CPU states.
[[inputs.disk]]
  ## By default stats will be gathered for all mount points.
  ## Set mount_points will restrict the stats to only the specified mount points.
  mount_points = ["/", "/var", "/home", "/home_local", "/boot", "/tmp"]
  ## Ignore mount points by filesystem type.
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs"]
[[inputs.diskio]]
[[inputs.ethtool]]
  normalize_keys = ["snakecase", "trim", "lower", "underscore"]
  interface_exclude = ["br-*"]
[[inputs.hddtemp]]
  devices = ["*"]
[[inputs.kernel]]
[[inputs.kernel_vmstat]]
[[inputs.mem]]
[[inputs.net]]
  ignore_protocol_stats=true
[[inputs.processes]]
[[inputs.procstat]]
  ## Pattern as argument for pgrep (ie, pgrep -f <pattern>)
  pattern = "rtctk"

  ## Properties to collect. Available options are cpu, limits, memory, mmap, sockets
  properties = ["cpu", "memory", "sockets"]

  ## Protocol filter for the sockets property. Available options are all, tcp4, tcp6, udp4, udp6, unix.
  socket_protocols = ["tcp4", "udp4", "unix"]

  ## Mode to use when calculating CPU usage. Can be one of 'solaris' or 'irix'.
  mode = "solaris"
[[inputs.swap]]
[[inputs.system]]
[[inputs.temp]]

# output for InfluxDB 3.x (over v2 API)
[[outputs.influxdb_v2]]
  urls = ["http://localhost:8181"]
  token = "YOUR INFLUXDB OPERATOR TOKEN"
  bucket = "elt_rtc_tk"
  insecure_skip_verify = true

The following plugins are required by the RTC Toolkit monitoring setup:

  • [[inputs.procstat]] collects statistics from matching RTC Toolkit processes.

  • [[inputs.socket_listener]] receives metrics, state changes, and alerts sent by RTC Toolkit components.

  • [[outputs.influxdb_v2]] writes the collected data to InfluxDB 3 through its InfluxDB v2 compatibility API.

Note

Telegraf 1.36.4 uses the outputs.influxdb_v2 plugin for InfluxDB 3.

When InfluxDB authentication is enabled, replace the token placeholder in the output plugin with the InfluxDB administrator token. Without a valid token, Telegraf cannot write data to the database.

Warning

The default procstat pattern matches processes whose names contain rtctk. If the deployed components use different names, update the pattern. Regular expressions can be used, for example:

pattern = "rtctk|your_project"

Some process metrics may require Telegraf to run as the same user as the RTC Toolkit components. To run Telegraf as eltdev, create a systemd override:

# systemctl edit telegraf.service

Add:

[Service]
User=eltdev

Reload systemd and restart Telegraf after changing the service:

# systemctl daemon-reload
# systemctl restart telegraf

Otherwise, start Telegraf normally:

# systemctl start telegraf

Verify its status:

# systemctl status telegraf

Grafana

Grafana displays the metrics stored in InfluxDB.

Start the Grafana system service:

# systemctl daemon-reload
# systemctl start grafana-server

Verify that it is running:

# systemctl status grafana-server

To start Grafana automatically after reboot:

# systemctl enable grafana-server

Grafana listens on port 3000 by default and can be opened at http://localhost:3000.

The initial credentials are:

  • Username: admin

  • Password: admin

Grafana prompts the user to change the password after the first login.

Import RTC Toolkit Resources

RTC Toolkit provides predefined Grafana data sources, variables, and dashboards. They can be imported with the rtctkConfigTool grafana-import command.

The import command accesses the Grafana HTTP API and therefore requires a Grafana service-account token.

Create a Grafana Service Account

Using the Grafana user interface:

  1. Open Administration.

  2. Select Users and access.

  3. Select Service accounts.

  4. Create a service account.

  5. Assign it the Admin organization role.

  6. Open the service account and select Add service account token.

  7. Choose a token name and expiration date.

  8. Generate and copy the token.

The token is displayed only when it is created.

Configure the InfluxDB Data-Source Token

When InfluxDB authentication is enabled, edit:

$INTROOT/resource/grafana/rtctk/secrets/datasource-tokens.json

Set the token associated with the RTC Toolkit InfluxDB data source:

{
   "6d724a58-b055-4e9c-98e5-8263eba19b70": "YOUR INFLUXDB ADMIN TOKEN"
}

The Grafana resource import can be performed without this file when InfluxDB authentication is disabled.

When authentication is enabled, the data source may still be imported without the token, but it will not be able to query InfluxDB until valid credentials are configured.

Run the Import

When InfluxDB authentication is enabled:

$ rtctkConfigTool --log-level=INFO grafana-import \
    --token=<GRAFANA_SERVICE_ACCOUNT_TOKEN> \
    --secrets=$INTROOT/resource/grafana/rtctk/secrets/datasource-tokens.json

When InfluxDB authentication is disabled:

$ rtctkConfigTool --log-level=INFO grafana-import \
    --token=<GRAFANA_SERVICE_ACCOUNT_TOKEN>

After the import completes, open Grafana and verify that the RTC Toolkit data source and dashboards are available.

Install from Source Code - Optional

RTC Toolkit can also be built and installed from a source-code release tarball. This procedure is primarily intended for developing or modifying RTC Toolkit, testing unreleased changes, debugging, and building the documentation.

For normal installation and use of a released RTC Toolkit version, use the RPM installation procedure described earlier in this chapter.

Important

When RTC Toolkit is built and installed from source, do not load the RPM-provided rtctk module in private.lua.

Use the following configuration:

local introot = "/home_local/eltdev/INTROOT"
local dataroot = "/home_local/eltdev/DATAROOT"

setenv("INTROOT", introot)
setenv("PREFIX", introot)
setenv("DATAROOT", dataroot)

-- RTCTK will be built and installed from source into INTROOT.
-- The RPM-provided rtctk module is therefore not loaded.

load("ddt")
load("cut")
load("mal")
load("ciisrv")
load("introot")

prepend_path("CFGPATH", dataroot .. "/config/persistent_repo")

Replace the introot and dataroot values when using different installation locations.

The Machine Preparation and Account Configuration sections remain applicable. Some examples and integration tests require the CII, Consul, and Nomad services to be configured and running. These services are not required merely to compile RTC Toolkit. The optional monitoring services are not required for a source build.

Installation of Dependencies

To be able to compile and use the RTC Toolkit, the dependencies listed in Release Notes section need to either be installed as RPM packages or be built and installed from source code first.

The package set below includes the dependencies required to build RTC Toolkit, together with the additional tools required by its unit and integration tests. The complete set of needed software can be installed as RPM packages with the following command:

# dnf -y install \
    elt-wtools \
    gcc \
    gcc-c++ \
    gtest \
    gmock \
    boost-devel \
    python3-devel \
    python3-pytest \
    python3-pytest-custom_exit_code \
    python3-pytest-qt \
    libatomic \
    guidelines-support-library-devel \
    cli11-devel \
    fmt-devel \
    libbacktrace-devel \
    google-benchmark-devel \
    yaml-cpp-devel \
    json-devel \
    CCfits-devel \
    cfitsio-devel \
    libpcap-devel \
    libppconsul-devel \
    tbb-devel \
    pybind11-devel \
    openblas \
    fast-dds-devel \
    elt-taiclock-devel \
    elt-llnetio-devel \
    elt-mal-devel \
    elt-msgsend \
    elt-stdif-devel \
    elt-metadaqif-devel \
    elt-rad-devel \
    elt-ddt-devel \
    elt-cut-devel \
    elt-cut-widgets-devel \
    elt-common-system \
    elt-roadrunner-numapp-devel \
    elt-roadrunner-ipcq-devel \
    elt-roadrunner-perfc-devel \
    elt-ciisrv-cii-common-types-devel \
    elt-ciisrv-client-api-devel \
    elt-ciisrv-oldb-client-devel \
    elt-ciisrv-config-ng-devel \
    elt-ciisrv-qt-widgets \
    pyside6-tools \
    python3-pyside6 \
    python3-click \
    python3-numpy \
    python3-jinja2 \
    python3-astropy \
    python3-traitlets \
    python3-taurus \
    python3-taurus_pyqtgraph \
    python3-wheel \
    python3-setuptools \
    python3-pip \
    python3-ipython \
    elt-devenv-doxygen-filter \
    doxygen \
    plantuml \
    python3-pillow \
    python3-sphinx \
    python3-sphinx-eso-theme \
    python3-sphinxcontrib-plantuml \
    python3-psutil \
    python3-pyyaml \
    elt-ciigui-log-gui \
    elt-ciigui-oldb-gui \
    elt-ciisrv-postinstall \
    elt-ciisrv-tooling \
    elt-ciisrv-robot-library \
    elt-nomad-robot-library \
    elt-oldbloader \
    elt-etr \
    pylint

After these packages have successfully installed, log out and back into the host for the environment variables to be updated.

Installation of the RTC Toolkit

Download the tarball for RTC Toolkit version 6.0.0 from ESO Gitlab. Unpack it and then execute the steps below to build and install the software.

$ cd rtctk-*/
$ waf --prefix=$INTROOT configure
$ waf build
$ waf install

Note

There are some optional dependencies in the toolkit. These may be indicated as “not found” during the configure step. For example, cuBLAS is optional and only needed if building on a machine that has GPUs. If there are any mandatory dependencies that cannot be found then the configure step will fail as expected.

Documentation (manuals and API reference) can be generated by invoking:

$ waf configure --with-docs
$ waf build --with-docs

The result can be viewed by opening the respective index.html files under build/doc/.

To allow setting the NUMA and thread policies in the component configurations delivered by the RTC Toolkit the following commands need to be run as root after the installation completes (The $INTROOT variable will need to be replaced with the correct path under the root account):

# setcap cap_sys_nice,cap_ipc_lock+ep $INTROOT/bin/rtctkTelRepub
# setcap cap_sys_nice,cap_ipc_lock+ep $INTROOT/bin/rtctkRtcSupervisor
# setcap cap_sys_nice,cap_ipc_lock+ep $INTROOT/bin/rtctkMudpiPub

Note

A similar setcap command invocation will be needed for each Telemetry Subscriber or Data Task instantiation built by the end user using the toolkit, if custom NUMA or thread policies are required.

Verify Correct Installation

To verify the build of RTC Toolkit, it is possible to run the unit tests by invoking:

$ cd rtctk-*/
$ waf test --alltests

For a more comprehensive verification that the RTC Toolkit was installed correctly, run the end-to-end integration test as follows:

$ cd test/_examples/exampleEndToEnd
$ etr -v

The integration test is expected to terminate successfully after running for about one minute.