This page is your “early-warning system.” It keeps an eye on the services that actually run your hosting stack (web, mail, DNS, database, FTP and a few core system bits). When something blinks red, you’ll see it here, and you can decide what the watchdog should do about it automatically.

What you can do here

• See health at a glance — each service shows a status badge: Active, Inactive, Failed, or Not installed.
• Decide what the watchdog should do when a service is down: Restart, Start, Stop, or None (alert only).
• Turn monitoring on/off per service with a simple checkbox.
• Pick the check interval (how often the watchdog looks), and who gets notified by email.
• Control the watchdog itself — start, stop, or restart it with the buttons at the top.
• Refresh a single row if you’ve just made a change and want a quick re-check.

How it’s organized

• Services are grouped by category: Web, Database, Mail, DNS, File Transfer, Security, and System.
• The list comes from your Services configuration, plus a few important OS daemons (e.g., SSH, crond, rsyslog).
• PHP user pools are not listed here (they’re monitored per account elsewhere).

What “Enabled” and “Action on failure” mean

• Enabled — the watchdog will check this service on a schedule. Uncheck to ignore it.
• Action on failure — what to do if the service isn’t healthy:
  • Restart — best default; brings a stalled unit back to life.
  • Start — useful if you want it kept on but never restarted blindly.
  • Stop — only for services you want forcibly stopped if they come up by mistake.
  • None (alert only) — do nothing automatically, just send an email.

When the watchdog says a service is “healthy”

• It asks systemd for the unit state. We treat active and reloading as OK.
• For Apache and Nginx we also do a quick HTTP probe to http://127.0.0.1/. If the port responds with a 2xx/3xx code, it’s healthy; if not, we mark it as an HTTP failure and follow your action.

Email notifications

• Add one or more addresses (comma-separated). When a service fails, you’ll get a message with the unit state, a short reason, and the last few journal lines to speed up troubleshooting.

Watchdog controls (top right)

• Start — launches the background watcher if it isn’t running.
• Stop — pauses monitoring (useful during maintenance).
• Restart — reloads it cleanly after you change many settings.

Saving your setup

• Click Save Changes to write your preferences to the monitor config file. You don’t need to restart the watchdog manually — it will pick up the new settings on its next loop (or you can restart it immediately with the button).

Where settings live

• All monitor settings are stored in /opt/shm/.shm/configuration/monitor.yaml:
  • loop_delay — your check interval in seconds.
  • notifications — the email list.
  • monitored — per-service flags and the action to take.

Good defaults

• Keep an eye on: Apache/Nginx, MariaDB, Exim, Dovecot, PowerDNS, Pure-FTPd, SSH, crond.
• Set action to Restart for most of these. For SSH, consider None (alert only) to avoid surprises if you’re working remotely.

Background Watchdog (monitor service)

Behind the scenes there’s a lightweight script that does the actual watching and healing. It runs as a systemd service and reads your preferences from the same config file the page above edits.

What it does every loop

• Reads /opt/shm/.shm/configuration/monitor.yaml to know which services are enabled, what actions to take, who to notify, and how long to sleep between checks.
• Asks systemd if each service is healthy. For web servers it also does a local HTTP probe.
• If a service isn’t healthy, it follows your action (Restart, Start, Stop, or None), logs what happened to syslog, and emails a short report with the last journal lines.
• Special case: for CSF/LFD it calls the appropriate csf command after the systemd action to fully apply the firewall state.

Where it runs from

• Systemd unit: monitor.service (created automatically the first time you start it from the UI).
• Process title: shm monitor so it’s easy to spot.

What counts as “healthy”

• States active or reloading are considered fine (so reloads don’t trigger alarms).
• For Apache/Nginx, a local HTTP 2xx/3xx response also has to pass. If it doesn’t, we mark it as http-failed and act accordingly.

Logging and email

• Logs to the system journal under the monitor tag (check with journalctl -t monitor).
• Email comes from monitor@your-hostname, one message per failure event with a concise reason and the last ten journal lines for that unit.

Tuning

• Check interval: sensible default is 30–60 seconds. The script sleeps exactly that amount between loops.
• HTTP probe timeout: 5 seconds — enough to catch real stalls, short enough to move on quickly.
• Scope: add or remove services from monitoring on the page above; no need to edit the script.

Manual controls (advanced)

• Start/stop/restart via the page controls, or with systemd: systemctl start|stop|restart monitor.
• Config lives at /opt/shm/.shm/configuration/monitor.yaml. You can edit by hand if needed, but the page keeps it tidy.