The SR Linux is a suite of modular, lightweight applications running like any others in a Linux environment. Each SR Linux application supports a different protocol or function, such as BGP, LLDP, AAA, and so on. These applications use gRPC and APIs to communicate with each other and external systems over TCP.
One SR Linux application, the application manager (app_mgr), is itself responsible for monitoring the health of the process IDs running each SR Linux applications, and restarting them if they fail. The application manager reads in application-specific YAML configuration and YANG models, and starts each application (or allows an application not to start if there no configuration exists for it). There is an instance of the app_mgr that handles applications running on the CPM, and an instance of the app_mgr on each IMM that handles applications running on the line card.
In addition to the Nokia-provided SR Linux applications, the SR Linux supports installation of user-defined applications, which are managed and configured in the same way as the default SR Linux applications.
This chapter presents examples of installing an application in SR Linux, managing installed SR Linux applications, and configuring settings for an SR Linux application by modifying its YAML configuration.
To install an application, copy the application files into the appropriate SR Linux directories, then reload the application manager and start the application.
The example in this section installs an application called fib_agent. The application consists of files named fib_agent.yml, fib_agent.sh, fib_agent.py, and fib_agent.yang. The fib_agent.yml file is installed in the /etc/opt/srlinux/appmgr/ directory. The .yml file for a user-defined application must reside in this directory in order for the app_mgr to read its YAML configuration.
The .yml file defines the locations of the other application files. The other application files can reside anywhere in the system other than in the /opt/srlinux/ directory or any tempfs file system.
In this example, the fib_agent.sh and fib_agent.py files are installed in the directory/user_agents/, and the fib_agent.yang file is installed in the directory/yang/. The locations for these files are defined in the fib_agent.yml file.
To start an SR Linux application instance, use the start option in the tools system app-management command. To terminate a running application instance and restart it, use the restart option.
Examples:
To start an SR Linux application instance:
To restart an SR Linux application instance:
You can use the stop, quit, or kill options in the tools system app-management command to terminate an SR Linux application.
Examples:
To terminate an application gracefully:
To terminate an application and generate a core dump:
To terminate an application immediately:
Reloading an application causes the app_mgr to reread the application’s YAML configuration and restart the application using settings in its YAML file.
Example:
To reload the configuration of the app_mgr application:
You can display statistics collected for an application with the info from state command. To reset the statistics counters for the application, use the statistics clear option in the tools system app-management command.
Example:
To reset the statistics counters for an application:
An application may have one or more operations that are restricted by default. For example, the linux_mgr application has stop, quit, and kill as restricted operations, meaning that these options are not available when entering the tools system app-management command for the linux_mgr application.
Table 14 lists the restricted operations for each SR Linux application.
Application | Restricted operations |
aaa_mgr | reload |
acl_mgr | reload |
app_mgr | start, stop, restart, quit, kill |
arp_nd_mgr | reload |
bfd_mgr | reload |
bgp_mgr | reload |
chassis_mgr | stop, quit, kill, reload |
device_mgr | reload |
dhcp_client_mgr | stop, reload |
fib_mgr | reload |
gnmi_server | reload |
idb_server | start, stop, restart, quit, kill, reload |
json_rpc_config | reload |
linux_mgr | stop, quit, kill |
lldp_mgr | reload |
log_mgr | reload |
mgmt_server | start, stop, quit, kill, reload |
mpls_mgr | reload |
net_inst_mgr | start, stop, quit, kill, reload |
oam_mgr | reload |
plcy_mgr | reload |
qos_mgr | reload |
sdk_mgr | reload |
static_route_mgr | reload |
supportd | reload |
xdp_cpm | stop, quit, kill, reload |
xdp_lc | reload |
Restricted options are specified in the restricted-operations setting in the YAML file for the application.
To configure an SR Linux application, edit settings in the application’s YAML file, then reload the application manager to activate the changes.
The example in this section shows how to configure an application to specify the action the SR Linux device takes when the application fails. If an SR Linux application fails a specified number of times over a specified time period, the SR Linux device can reboot the system or attempt to restart the application after waiting a specified number of seconds.
For example, if the aaa_mgr application crashes 5 times within a 500-second window, the SR Linux device can be configured to wait 100 seconds, then restart the aaa_mgr application.
The following actions can be taken if an SR Linux application fails:
If you stop or restart an application using the tools system app-management command in the SR Linux CLI, it is not considered an application failure; the failure action for the application, if one is configured, does not occur. However, if the failed application waits a specified period of time (or forever) to be restarted, or has been moved into error state, you can restart the application manually with the tools system app-management application restart CLI command.
To configure the failure action for an application: