Manifest Reference
The Manifest block contains metadata about the service script. This metadata is parsed by the SSI Agent when adding a service.
Manifest Format
Each manifest field is a comment line with the format:
1# field: valueFields
name (Required)
The human-readable name of the service.
1# name: API HealthConstraints:
- Minimum: 3 characters
- Maximum: 60 characters
- Allowed: Letters, numbers, spaces, hyphens
What it's used for:
- Display name in the mobile app
- Deriving the service ID (name → kebab-case)
Examples:
1# --- Manifest --- #
2# name: API Health
3# name: ZFS Zpool Health
4# name: System Updates
5# name: Daily Backup Verifierdescription (Required)
A short description of what the service monitors.
1# description: Checks the health of an API that has a health check endpointConstraints:
- Maximum: 255 characters
What it's used for:
- Displayed in the mobile app
- systemd unit file Description field
Examples:
1# description: Checks the health of an API endpoint
2# description: Monitors available system updates on Debian/Ubuntu
3# description: Verifies BTRFS filesystem integrity via scrubversion (Required)
The version of the service script.
1# version: 1.0Format:
- Any string (typically semver like
1.0,1.0.0,2.1.3) For simplicity, we recommend x.y format like1.0,1.1,2.0.
What it's used for:
- Tracking script versions
- Future: Detecting when to update
Examples:
1# version: 1.0
2# version: 1.1
3# version: 2.0schedule (Required)
The schedule for running the service script, in systemd OnCalendar format.
1# schedule: *:0/01:00Format: systemd OnCalendar expression
Common patterns:
| Pattern | Meaning |
|---|---|
*:0/01:00 | Every 1 minute |
*:0/05:00 | Every 5 minutes |
*:0/15:00 | Every 15 minutes |
*-*-* 06:00:00 | Daily at 6:00 AM |
*-*-* 00:00:00 | Daily at midnight |
Mon *-*-* 00:00:00 | Every Monday at midnight |
*-*-01 00:00:00 | First of every month at midnight |
Understanding the format:
DayOfWeek Year-Month-Day Hour:Minute:Second
Examples:
*-*-* 06:00:00 = Every day at 06:00:00
Mon *-*-* 06:00:00 = Every Monday at 06:00:00
*:0/5:00 = Every 5 minutes (at :00, :05, :10, etc.)
*:*:0/30 = Every 30 seconds
Testing your schedule:
Use systemd-analyze calendar to verify:
1systemd-analyze calendar "*:0/05:00"Output:
Original form: *:0/05:00
Normalized form: *-*-* *:00/5:00
Next elapse: Fri 2024-01-15 10:35:00 UTC
(in UTC): Fri 2024-01-15 10:35:00 UTC
From now: 2min 30s left
timeout (Optional)
Maximum execution time in seconds. The script will be killed if it exceeds this duration.
1# timeout: 30Default: 20 seconds
Constraints:
- Minimum: 1 second
- Recommended maximum: Match your schedule interval
What it's used for:
- systemd
TimeoutSecdirective - Preventing hung scripts from blocking the system
Examples:
1# timeout: 10 # Quick API check
2# timeout: 60 # Longer health check
3# timeout: 300 # 5-minute ZFS scrub status check
4# timeout: 86400 # Full day for very long operationsComplete Manifest Example
1# name: API Health
2# description: Checks the health of an API that has a health check endpoint
3# version: 1.0
4# schedule: *:0/01:00
5# timeout: 10Validation
When you run ssi add, the manifest is validated:
| Field | Validation |
|---|---|
name | Required, 3-60 chars |
description | Required, max 255 chars |
version | Required |
schedule | Required, valid OnCalendar format |
timeout | Optional, must be > 0 if provided |
Error examples:
ValueError: Service name must be between 3 and 60 characters.
ValueError: Service description cannot exceed 255 characters.
ValueError: Service script must contain a schedule metadata.
ValueError: Invalid schedule format...
Service ID Derivation
The service ID is automatically derived from the name field:
- Convert to lowercase
- Replace spaces with hyphens
Examples:
| Name | Service ID |
|---|---|
| API Health | api-health |
| ZFS Zpool Health | zfs-zpool-health |
| System Updates | system-updates |
| Daily Backup Verifier | daily-backup-verifier |
The service ID is used for:
- systemd unit file names (
ssi-api-health.service) - Log file names (
api-health.log) - CLI commands (
ssi service status api-health)