Example: system watchdog configuration

This example configures the system watchdog for unattended critical devices so they recover automatically from faults with less on-site intervention.

Scenario

An acquisition device at a remote site must run continuously, 24/7, without on-site supervision.

Step 1: Verify the watchdog service

systemctl status jelina-watchdog

Confirm that the watchdog service is running normally. If it is stopped, start it and enable startup at boot:

systemctl start jelina-watchdog
systemctl enable jelina-watchdog

Step 2: Verify application recovery configuration

The watchdog works best with application restart policies. Configure automatic restart for critical applications:

• Containerized applications: --restart always, or restart: always in the orchestration file.
• Native applications: restart: always in the ProgramSet configuration.

Step 3: Verify the recovery workflow

Validate automatic recovery at each level:

# 1. Application level: stop the application and observe automatic recovery
systemctl stop <application-service>
systemctl status <application-service>    # Should automatically resume operation

# 2. System level: observe continued watchdog operation
systemctl status jelina-watchdog

Step 4: Add cloud monitoring (optional)

After connecting to JelinaCloud, configure alerts for immediate fault notification:

• Resource alert thresholds for temperature, memory, storage, and CPU.
• Cloud retention of runtime logs for later investigation.

Results

Fault type	Automatic handling
Application exits abnormally	Restart policy restores operation
System stops responding	Watchdog initiates recovery
System corruption	A/B switching provides fallback

Related documentation

• Watchdog — Mechanism details
• Fleet management and remote maintenance — Cloud monitoring and alerts