This document outlines the architecture, service management, and packaging strategy for GriffonAV on Linux. Since an antivirus requires high privileges and constant background monitoring, we will focus on a Systemd-managed Daemon approach.

1. System Architecture Overview

The GriffonAV ecosystem consists of four main components interacting via a Unix Domain Socket.

• griffond (Daemon): The brain. Runs as a background service (often as root or a dedicated griffon user). It loads plugins and performs scans.
• griffon-cli / griffon-gui (Clients): Stateless interfaces that send commands (e.g., SCAN /home/user) to the daemon.
• Unix Socket (/run/griffon.sock): The communication bridge. Using a socket is faster and more secure than local network ports.
• Plugins (.so files): Dynamic libraries loaded by the daemon from system and user paths.

2. Connecting the Components (The Logic)

To ensure the app "just works," the client must be able to wake the daemon.

The Socket Activation Method (Recommended)

Instead of the CLI manually spawning a process (which can lead to "zombie" processes), Linux uses Socket Activation.

1. Systemd listens on /run/griffon.sock.
2. When you run griffon-cli scan, it tries to write to that socket.
3. Systemd intercepts this, realizes the daemon isn't running, starts griffond, and hands off the connection.

The Config Hierarchy

To support both "Default" and "Custom" plugins, your Rust code should look in these locations in order:

1. System: /usr/lib/griffon/plugins/ (Read-only, default plugins).
2. User: $HOME/.config/griffon/plugins/ (User-added plugins).