The OpenSAND daemon is a component present in every host running OpenSAND programs. Its role is to manage the programs (mainly the OpenSAND core) and to report the status of these programs to the OpenSAND Manager and Collector.
The OpenSAND daemon uses a zeroconf protocol (avahi) in order to detect the presence of other OpenSAND entities on the network, and retrieve information about them. With the configuration collected using this service, and the one received from the manager, OpenSAND daemon prepares the configuration used by the core program (e.g. routing, setting up the virtual interfaces, etc.) before launching it. Finally, upon request from the manager, it launches and stops the core program.
The OpenSAND Daemon is distributed with a service that executes the sand-daemon script (described below). The service is launched at start-up, and executes an auxiliary script (
/usr/libexec/opensand/write_initialize_config) to collect the daemon configuration from
debconf before launching the binary. This script generates the daemon configuration file in
To check the status of the service, execute the following command (for systems using systemd):
sudo systemctl status opensand-daemon
This will print the status, as well as the last logs emitted by the daemon, as follows:
● opensand-daemon.service - Startup script for the OpenSAND daemon Loaded: loaded (/lib/systemd/system/opensand-daemon.service; enabled; vendor preset: enabled) Active: active (running) since jeu. 2018-09-20 17:00:40 CEST; 3 days ago Main PID: 12092 (sand-daemon) Tasks: 5 Memory: 13.5M CPU: 54.021s CGroup: /system.slice/opensand-daemon.service └─12092 /usr/bin/python /usr/bin/sand-daemon -c /etc/opensand/daemon.conf -q -v sept. 20 17:00:42 sat sand-daemon: listen on 0.0.0.0:5926 sept. 20 17:00:42 sat sand-daemon: Starting the output handler sept. 20 17:00:42 sat sand-daemon: listen for states on 0.0.0.0:5358 sept. 20 17:00:43 sat sand-daemon: set collector address: 172.20.42.19:56397 sept. 20 17:00:43 sat sand-daemon: Resend register messages because collector was restarted sept. 20 17:00:44 sat sand-daemon: process are not running, standbye interfaces sept. 20 17:00:48 sat sand-daemon: state server connected to manager: 172.20.42.19 sept. 20 17:00:49 sat sand-daemon: command server connected to manager: 172.20.42.19 sept. 20 17:00:49 sat sand-daemon: close connection sept. 20 17:01:10 sat sand-daemon: manager is stopped
The full history of logs can be accessed with the command
sudo journalctl -u opensand-daemon, or by reading the file
Should the necessity arise, the OpenSAND Daemon service can be restarted by executing:
sudo systemctl restart opensand-daemon
started by executing:
sudo systemctl start opensand-daemon
and stopped by executing:
sudo systemctl stop opensand-daemon
Before executing the sand-daemon executable, the opensand-daemon service performs two additional tasks:
write_initialize_configscript (installed by default at
/usr/libexec/opensand/). This script collects the daemon configuration stored by Debconf, and generates the
/etc/opensand, which contains all the daemon configuration. It also creates the virtual interfaces (
opensand_tap) using the
opensand_interfacesbinary, and sets the IP addresses to the EMU and LAN interfaces.
The sand-daemon executable can be executed manually using the following command, and requires the path of the configuration file (generated by
/usr/bin/python /usr/bin/sand-daemon -c /etc/opensand/daemon.conf
Supported command options can be displayed by running
/usr/bin/python /usr/bin/sand-daemon -h.
OpenSAND Daemon is composed of four main threads:
A list of running programs is shared between the state, command and output threads. The state thread checks and updates it; the command block can modify it, adding or removing programs; the output thread manages programs in order to check for incoming messages.
Moreover, the command thread handles interfaces and routes depending on manager commands to correctly configure the network. The route management is shared with service thread, that is able to detect other hosts on the network.
On startup, the main program starts the threads and waits a stopping signal.
The global architecture is illustrated in the figure below: