tutorial

Monitoring OpenSnitch Application Firewall with Vigilmon

OpenSnitch is a Linux application-level firewall that silently stops working when its daemon crashes. Here's how to monitor the daemon process, gRPC socket, SQLite event database, and DNS resolver health with Vigilmon.

OpenSnitch is an open-source Linux application firewall inspired by Little Snitch — it intercepts every outbound network connection and evaluates it against per-application rules, prompting you for decisions or enforcing pre-configured policies. The daemon (opensnitchd) runs as a system service in Go, exposes a gRPC socket at /tmp/osui.sock for the PyQt5/Gtk UI, and logs connection events to a SQLite database. The problem: when the daemon crashes, all outbound connections are silently permitted (or blocked, depending on your default policy) with no indication anything is wrong. Vigilmon monitors the daemon, gRPC socket, event database, and DNS resolver so a silent firewall failure triggers an immediate alert.

What You'll Set Up

  • OpenSnitch daemon process availability via systemd heartbeat
  • gRPC socket connectivity check
  • SQLite event database accessibility heartbeat
  • DNS resolver health monitoring
  • UI/notification server process health check
  • Connection decision queue depth monitoring
  • Event logging pipeline health heartbeat

Prerequisites

  • OpenSnitch installed and running on Linux (systemd service opensnitchd)
  • Root or sudo access to the host
  • A free Vigilmon account

Step 1: Monitor the OpenSnitch Daemon via systemd Heartbeat

OpenSnitch runs as a systemd service. The most reliable way to detect a daemon crash is to check service status and ping Vigilmon:

#!/bin/bash
# /usr/local/bin/opensnitch-daemon-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_DAEMON_HEARTBEAT_ID"

if systemctl is-active --quiet opensnitchd; then
    curl -s "$HEARTBEAT_URL"
fi

chmod +x /usr/local/bin/opensnitch-daemon-check.sh

Create the Vigilmon heartbeat:

  1. Log in to vigilmon.online and click Add Monitor → Cron Heartbeat.
  2. Set the expected interval to 1 minute.
  3. Copy the heartbeat URL into the script.

Schedule the check:

# /etc/cron.d/opensnitch-daemon-check
* * * * * root /usr/local/bin/opensnitch-daemon-check.sh

If the daemon crashes and systemctl is-active returns false, the script never pings Vigilmon, and you receive an alert within two minutes.

Step 2: Monitor the gRPC Socket Connectivity

The UI communicates with the daemon via a Unix domain socket at /tmp/osui.sock. If the socket file disappears (daemon restart, temp directory flush) or the daemon stops accepting gRPC connections, the UI goes blank and you lose visibility into connection events.

#!/bin/bash
# /usr/local/bin/opensnitch-grpc-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_GRPC_HEARTBEAT_ID"
SOCKET="/tmp/osui.sock"

# Check socket exists and daemon is listening on it
if [ -S "$SOCKET" ] && ss -xlp | grep -q "osui.sock"; then
    curl -s "$HEARTBEAT_URL"
fi

chmod +x /usr/local/bin/opensnitch-grpc-check.sh

Create a second Vigilmon heartbeat with a 1 minute interval and schedule:

* * * * * root /usr/local/bin/opensnitch-grpc-check.sh

If grpc-health-probe is installed, you can do a proper gRPC health check:

#!/bin/bash
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_GRPC_HEARTBEAT_ID"

if grpc-health-probe -addr=unix:/tmp/osui.sock > /dev/null 2>&1; then
    curl -s "$HEARTBEAT_URL"
fi

Install grpc-health-probe:

GRPC_HEALTH_PROBE_VERSION=v0.4.25
wget -qO /usr/local/bin/grpc-health-probe \
  "https://github.com/grpc-ecosystem/grpc-health-probe/releases/download/${GRPC_HEALTH_PROBE_VERSION}/grpc_health_probe-linux-amd64"
chmod +x /usr/local/bin/grpc-health-probe

Step 3: Monitor SQLite Event Database Accessibility

OpenSnitch logs every connection decision to a SQLite database (typically at /var/lib/opensnitch/history.db). A full disk, file permission change, or corruption stops event logging — you lose the audit trail for all outbound connections.

#!/bin/bash
# /usr/local/bin/opensnitch-db-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_DB_HEARTBEAT_ID"
DB_PATH="/var/lib/opensnitch/history.db"

# Try to read from the database and write a test record
if sqlite3 "$DB_PATH" "SELECT COUNT(*) FROM connections LIMIT 1;" > /dev/null 2>&1; then
    curl -s "$HEARTBEAT_URL"
fi

chmod +x /usr/local/bin/opensnitch-db-check.sh

Create a Vigilmon heartbeat with a 5 minute interval and schedule:

*/5 * * * * root /usr/local/bin/opensnitch-db-check.sh

Check the actual database path on your system:

# Find the OpenSnitch database
find /var/lib/opensnitch /home -name "*.db" 2>/dev/null
# Or check the config
grep -r "db" /etc/opensnitchd/default-config.json

Step 4: Monitor DNS Resolver Health

OpenSnitch intercepts DNS queries to resolve process-level connection metadata. If the configured DNS resolver becomes unreachable, hostname-based rules stop matching, potentially letting unmatched connections through under a permissive default policy.

Add a DNS monitor in Vigilmon:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://1.1.1.1/dns-query?name=vigilmon.online&type=A (or your configured resolver's DoH endpoint).
  3. Set Expected HTTP status to 200.
  4. Set Check interval to 2 minutes.
  5. Click Save.

If you use a local resolver (like systemd-resolved or dnsmasq), monitor it with a TCP port check:

  1. Click Add Monitor → TCP Port.
  2. Host: 127.0.0.1, Port: 53.
  3. Set Check interval to 1 minute.
  4. Click Save.

Step 5: Monitor Rule Database Integrity and Load Status

OpenSnitch rules are stored as JSON files in /etc/opensnitchd/rules/. A permission error or corrupt file prevents rules from loading after a daemon restart, reverting to the default policy silently.

#!/bin/bash
# /usr/local/bin/opensnitch-rules-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_RULES_HEARTBEAT_ID"
RULES_DIR="/etc/opensnitchd/rules"

RULE_COUNT=$(find "$RULES_DIR" -name "*.json" 2>/dev/null | wc -l)
VALID_RULES=0

for rule_file in "$RULES_DIR"/*.json; do
    if python3 -c "import json,sys; json.load(open('$rule_file'))" 2>/dev/null; then
        VALID_RULES=$((VALID_RULES + 1))
    fi
done

# Alert if no rules found or if valid count dropped significantly
if [ "$RULE_COUNT" -gt 0 ] && [ "$VALID_RULES" -eq "$RULE_COUNT" ]; then
    curl -s "$HEARTBEAT_URL"
fi

chmod +x /usr/local/bin/opensnitch-rules-check.sh

Schedule every 10 minutes:

*/10 * * * * root /usr/local/bin/opensnitch-rules-check.sh

Step 6: Monitor the UI / Notification Server Process

The OpenSnitch UI process (opensnitch-ui) handles connection prompts and the notification server. If it crashes, connection decision prompts stop appearing and you lose real-time visibility.

#!/bin/bash
# /usr/local/bin/opensnitch-ui-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_UI_HEARTBEAT_ID"

# Check if the UI process is running
if pgrep -x "opensnitch-ui" > /dev/null || pgrep -f "opensnitch-ui" > /dev/null; then
    curl -s "$HEARTBEAT_URL"
fi

chmod +x /usr/local/bin/opensnitch-ui-check.sh

Schedule every 2 minutes:

*/2 * * * * root /usr/local/bin/opensnitch-ui-check.sh

Note: if you run OpenSnitch in daemon-only mode without the UI (for policy enforcement without prompts), skip this step.

Step 7: Monitor Connection Decision Queue Depth

OpenSnitch evaluates connection decisions in real time. A high queue depth means the daemon is falling behind processing connections — potentially blocking legitimate traffic or causing application timeouts.

Check the daemon's queue metrics via its API (if your version supports it) or via log parsing:

#!/bin/bash
# /usr/local/bin/opensnitch-queue-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_QUEUE_HEARTBEAT_ID"
MAX_QUEUE_DEPTH=100

# Parse queue depth from daemon logs (adjust grep pattern to your log format)
QUEUE_DEPTH=$(journalctl -u opensnitchd --since "1 minute ago" --no-pager \
  | grep -oP "queue:\s*\K[0-9]+" | tail -1)

if [ -z "$QUEUE_DEPTH" ] || [ "$QUEUE_DEPTH" -lt "$MAX_QUEUE_DEPTH" ]; then
    curl -s "$HEARTBEAT_URL"
fi

Create a Vigilmon heartbeat with a 2 minute interval.

Step 8: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add email, Slack, or a webhook.
  2. For the daemon heartbeat, set Consecutive failures before alert to 1 — a crashed firewall is immediately critical.
  3. For the database and rule checks, set Consecutive failures before alert to 2 to avoid noise from transient file system delays.
  4. Consider a separate high-priority alert channel for daemon failures and a standard channel for UI and database issues.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Daemon heartbeat | systemd opensnitchd | Daemon crash, service failure | | gRPC socket | /tmp/osui.sock | Socket disappears, gRPC error | | SQLite database | /var/lib/opensnitch/history.db | DB corruption, disk full | | DNS resolver | Port 53 or DoH endpoint | DNS interception broken | | Rule integrity | /etc/opensnitchd/rules/ | Corrupt or missing rules | | UI process | opensnitch-ui PID | Prompt and notification failure | | Queue depth | journald logs | Decision backlog, performance |

OpenSnitch's daemon is the enforcement point for all outbound network policy. A silent crash means either all connections pass through unfiltered or all connections are blocked — both are catastrophic in different ways. Vigilmon's heartbeat and process monitors ensure you know within minutes when the daemon stops running, the socket disappears, or the rule database becomes inaccessible.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles