User Tools

Site Tools



OpenSAND Daemon

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.

OpenSAND Exploitation

opensan-daemon service

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 /etc/opensand/daemon.conf.

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[12092]: listen on
sept. 20 17:00:42 sat sand-daemon[12092]: Starting the output handler
sept. 20 17:00:42 sat sand-daemon[12092]: listen for states on
sept. 20 17:00:43 sat sand-daemon[12092]: set collector address:
sept. 20 17:00:43 sat sand-daemon[12092]: Resend register messages because collector was restarted
sept. 20 17:00:44 sat sand-daemon[12092]: process are not running, standbye interfaces
sept. 20 17:00:48 sat sand-daemon[12092]: state server connected to manager:
sept. 20 17:00:49 sat sand-daemon[12092]: command server connected to manager:
sept. 20 17:00:49 sat sand-daemon[12092]: close connection
sept. 20 17:01:10 sat sand-daemon[12092]: manager is stopped

The full history of logs can be accessed with the command sudo journalctl -u opensand-daemon, or by reading the file /var/log/opensand/daemon.log.

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:

  • Create the necessary working dir for the sand-daemon executable (/var/run/sand-daemon/)
  • Launch the write_initialize_config script (installed by default at /usr/libexec/opensand/). This script collects the daemon configuration stored by Debconf, and generates the daemon.conf file in /etc/opensand, which contains all the daemon configuration. It also creates the virtual interfaces (opensand_tun or opensand_tap) using the opensand_interfaces binary, and sets the IP addresses to the EMU and LAN interfaces.
  • The sand-daemon executable is launched afterwards, and runs in the background.

sand-daemon executable

The sand-daemon executable can be executed manually using the following command, and requires the path of the configuration file (generated by write_initialize_config):

/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 Software Design

OpenSAND Daemon is composed of four main threads:

  • a command thread, which listens for manager orders (run, stop, install, …).
  • a state thread, which waits a manager connection and then reports programs status.
  • a service thread, which announces the service the host supports (sat, st or gw) and discovers other hosts.
  • a output thread, which transmits statistics and logs from programs to the collector.

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:

opensand/testbed_description/management/daemon/index.txt · Last modified: 2019/06/11 16:22 (external edit)