Ensure and maintain the availability of its ServiceNav Box fleet

On the page

Need some help?

Purpose of this documentation

While the central platform is the heart of ServiceNav, the supervision boxes are the eyes of the company.
The ServiceNav Box (SNB or supervision box) allows you to :

  • Collect monitoring information on the client LAN or from an external source.
  • Transmit the collected data to the central platform via the VPN tunnel.
  • Send email alerts (regardless of VPN tunnel access).
  • Receive instructions given by the user via the web interface (immediate control, acknowledgement, configuration application).

It is essential to ensure that the supervision boxes are not unavailable.

This documentation will explain how to avoid SNB downtime and how to resolve certain problems if they occur.

Supervise your ServiceNav Boxes

Won't they teach you anything if they tell you that the best way to prevent equipment failure is to supervise it?
That's what ServiceNav is for!

When setting up a ServiceNav Box, the first two reflexes must be :

  • Self-supervision of the stall via the equipment model ServiceNav Box - self-monitoring.
    In terms of resources, it is very important to monitor the use of these resources:

    • CPU load: about 1vCPU per 1000 control points (to be adapted according to the control points used). A lack of CPU will lead to instability of the box and delays in the execution of the control points.
    • RAM: A lack of RAM can prevent checkpoints from being executed and can lead to service outages. nagios or openvpn resulting in a termination of supervision.
    • Disk space: a lack of disk space will cause the file system to be read-only and the supervision to become unstable or even stop.
  • Cross supervision via another box with the equipment model ServiceNav Box - Supervision by supervisor.
    The checkpoint Box-Live-Status allows to make sure that the supervised box has sent supervision data for the last X minutes.
    If this checkpoint passes CRITICALLY it is because the supervised SNB no longer sends data to the central platform and therefore the statuses present on the web interface are no longer current. It is imperative to take action to restore communication.

Important to note The supervision and maintenance of the stalls are the responsibility of the clients.

For more details, a webinar entirely dedicated to stalls and their supervision is available here : How to supervise your ServiceNav Box.
The supervision of the boxes is described at the end of the following documentation: Installation of an SNB

Solving problems with a ServiceNav Box

Even though the risks are greatly reduced through supervision, it is possible that a ServiceNav Box may experience downtime.
The following section will present some common scenarios and how to solve the problem.


  • Connection to the VPN tunnel impossible, high latency of the box in the VPN tunnel, untimely connection losses.
    -> Follow the solution : Check network access.
  • All checkpoints are in undetermined status.
    -> Follow the solution : Check network access.
    -> If the problem is still not solved: follow Restart remoteOperationBox and nagios.
  • The checks carried out by a ServiceNav Box have a very old time stamp.
    -> Follow the solution : Restart remoteOperationBox and nagios.
  • Unable to reload configuration on a Servicenav Box.
    -> Follow the solution : Restart remoteOperationBox and nagios.
  • Acquittals are not taken into account.
    -> Follow the solution : Restart remoteOperationBox and nagios.
  • Immediate controls launched from the web interface are not taken into account.
    -> Follow the solution : Restart remoteOperationBox and nagios.


Check network access

  1. Check SNB performance (CPU load, RAM, disk space) and add more if necessary.
  2. Check that the box is on time with the command date.
  3. Make sure that no changes/deletions of firewall rules have been made recently.
  4. Verify that the box has access to the ServiceNav VPN port on exit to the central platform.
    For the platform -> telnet $(awk -F '[ ]' 'NR==42 {print int($3)}' /etc/openvpn/client.conf)
    For the platform -> telnet $(awk -F '[ ]' 'NR==42 {print int($3)}' /etc/openvpn/client.conf)
    For an OnPremise platform -> telnet
    Functional access :

    If no access, take the necessary steps at the firewall.
  5. Make sure that the box's LAN IP address is not also assigned to another machine on the same network.

Restart remoteOperationBox and nagios

The Process remoteOperationBox  ensures the sending and receiving of messages between the box and the central platform.
If it doesn't work anymore:

  • The supervision data collected by the box will no longer be sent to the central platform.
  • All actions performed on the web interface towards the box will no longer be transmitted to it.

The Process nagios ensures the scheduling of inspection points. It communicates with remoteOperationBox to take into account immediate control executions or acknowledgements made through the web interface.

Carry out the following operations:

  • Connect to the ServiceNav Box with an SSH client.
  • Stop the process remoteOperationBox :
    • Execute: service remoteOperationBox stop
    • Check that no more processes are running : ps aux | grep remoteOperationBox
    • If this is the case, manually kill the process instances: Kill. or kill - 9 if resistance
  • Stop the process nagios :
    • Execute: nagios stop service
    • Check that no more processes are running : ps aux | grep nagios (the stop of nagios may take a little time, redo the order several times ps).
    • If there are any processes left nagios kill them manually: Kill. or kill - 9 in case of resistance.
  • At this point, remoteOperationBox and nagios must no longer be running and no processes must be present at the output of the control system. ps.
  • Restart the service nagios : nagios start service
  • Restart the service remoteOperationBox : service remoteOperationBox start and check the presence of 6 instances of the service.
  • Check on the web interface that the application is working again.

If the problems persist after the restart of the 2 services, thank you to contact ServiceNav support.

Ensuring the recovery of a ServiceNav Box

Three cases of use:

  • The ServiceNav Box is completely unusable despite a reboot. Cannot connect to it via SSH or a local console.
    -> Follow this documentation : Ensuring the PRA of a ServiceNav BoxSee the chapter "Complete replacement of a ServiceNav Box" in the chapter "Complete replacement of a ServiceNav Box".
  • Migrate a defective but still accessible ServiceNav Box to a new one.
    -> Follow this documentation : Migration ServiceNav Box
  • Perform a rollback of the ServiceNav Box using a backup.
    -> Follow this documentation : Ensuring the PRA of a ServiceNav BoxSee the chapter "Rollback from a backup of the ServiceNav Box" in the chapter "Rollback from a backup of the ServiceNav Box".

This may also be of interest to you

Ensuring the PRA of a ServiceNav Box

Configuring a ServiceNav Box to use an authenticated mail server

Replacing a Ubuntu 12.04 ServiceNav Box with a Ubuntu 4.0 ServiceNav Box 16.04

fr_FRFrench en_USEnglish

Welcome to ServiceNav!

Need help? More information about our products? Write to us!
You have taken note of our privacy policy.


While the epidemic lasts, ensure the availability and performance of your IT services for teleworking, with ServiceNav!

Following the government's call to mobilize to help businesses overcome the current health and economic context, we help you, free of charge, to ensure the complete monitoring of your teleworking environments: VPN, VDI, Teams, Skype Enterprise, Citrix... Objectives: collection, availability and usage indicators, dashboards to support your communication.
We use cookies to ensure that you have the best possible experience on our site, and if you continue to use this site, we will assume that you are satisfied with it.

Reserve your place

You have taken note of our privacy policy.