OPERATOR MANUAL syntropctl(1) Reference Guide • System administration & automated failure triage

Global Options

Flag Type Description
--json Boolean Format all output as machine-readable JSON for automation and jq processing.
-v, --verbose Count Enable detailed debug logging to stderr including raw Varlink messages.
-h, --help Flag Print help information and subcommand summary.
-V, --version Flag Print version information.

1. syntropctl status [DAEMON]

Inspects daemon socket connectivity, round-trip latency, and interface health.

DIAGNOSTIC

Sends an org.varlink.service.GetInfo ping to all active sockets under /run/syntrop/.

$ syntropctl status
DAEMON       SOCKET                                  STATE    LATENCY   INTERFACES
inferenced   /run/syntrop/io.syntrop.Inference1      ACTIVE    0.41ms   io.syntrop.Inference1, org.varlink.service
modeld       /run/syntrop/io.syntrop.Model1          ACTIVE    0.32ms   io.syntrop.Model1, org.varlink.service
contextd     /run/syntrop/io.syntrop.Context1        ACTIVE    0.28ms   io.syntrop.Context1, org.varlink.service
toold        /run/syntrop/io.syntrop.Tool1           ACTIVE    0.35ms   io.syntrop.Tool1, org.varlink.service
runtimed     /run/syntrop/io.syntrop.Runtime1        STANDBY   0.15ms   io.syntrop.Runtime1, org.varlink.service
routerd      /run/syntrop/io.syntrop.Router1         ACTIVE    0.38ms   io.syntrop.Router1, org.varlink.service

System Status: OPERATIONAL (All sockets listening; 0 MB idle RAM footprint)

2. syntropctl explain <UNIT>

Diagnose failure or state of a target systemd service unit using AI correlation.

TRIAGE

Executes an end-to-end incident triage inquiry. Correlates unit failure signals with recent configuration drift, journal logs, and PSI pressure to pinpoint exact root causes.

$ syntropctl explain nginx.service
● nginx.service - The NGINX HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
     Active: failed (Result: exit-code) since Wed 2026-09-24 04:52:10 UTC; 42s ago

INCIDENT CHRONOLOGY:
  ├─ 04:50:12: Package upgrade 'openssl-libs' (3.0.7 -> 3.2.0)
  ├─ 04:51:30: Config modified: /etc/nginx/nginx.conf (+ssl_protocols TLSv1.3)
  └─ 04:52:10: Process terminated with status 1 (nginx: [emerg] invalid directive)

ROOT CAUSE ANALYSIS:
  The directive 'ssl_protocols TLSv1.3' inside http {} block conflicts with
  upstream template syntax in /etc/nginx/conf.d/default.conf line 14.

SUGGESTED ACTION:
  # systemctl revert nginx.service
  Or run automated remediation:
  $ syntropctl run revert_config /etc/nginx/nginx.conf

3. syntropctl devices

Inspect compute accelerators, VRAM allocation, and PSI pressure stalls.

HARDWARE
$ syntropctl devices
PLANE ID           KIND       DEVICE NAME                 TOTAL VRAM   ALLOCATED    PRESSURE
drm-renderD128     DRM_GPU    NVIDIA GeForce RTX 4090     24.00 GiB     8.25 GiB    Normal (0.0% some)
cpu-amx-0          CPU_AMX    Intel Xeon Platinum 8480+   64.00 GiB     0.00 GiB    Normal (0.2% some)

Active Leases:
  lease-4921-bc  [Interactive]     payment.service   4.00 GiB  (plane: drm-renderD128)
  lease-7712-aa  [EmergencyTriage] sentry-enclave    4.25 GiB  (plane: drm-renderD128)

4. syntropctl models & syn pull <model>

Manage content-addressable model cache in /var/lib/models and retrieve models from Hugging Face or registry.

STORAGE & PULL

Pull models using aliases (qwen2.5:0.5b, qwen2.5:1.5b, llama3.2:1b, smollm2:360m, gemma4:e2b) or Hugging Face repositories (org/repo):

$ syn pull qwen2.5:0.5b
Resolving model: qwen2.5:0.5b
  Target: qwen2.5:0.5b
  Source: https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/main/qwen2.5-0.5b-instruct-q4_k_m.gguf
qwen2.5 [00:00:02] [########################################] 397.66 MiB/397.66 MiB (0s) Download complete
  SHA-256: 7f9a12bc81e3a4e98f01b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708
Successfully pulled and registered qwen2.5:0.5b
$ sudo syn setup --family qwen

Automatically size hardware envelopes, pull and pin draft & primary models via modelctl bootstrap, generate speculative router configurations, and reload services:

=== Syntrop Setup: Family [qwen] (Envelope: auto) ===
[1/3] Sizing hardware envelope and dispatching to modelctl bootstrap...
  CPU Cores: 12 | Host RAM: 14.8 GB avail (7.4 GB draft budget)
  Selected CPU Draft: qwen2.5:0.5b [Q8_0]
  [✓] modelctl bootstrap completed successfully.
[2/3] Generating speculative routerd.toml configuration...
  [✓] Speculative router configuration written to /etc/syntrop/routerd.toml
[3/3] Reloading routerd.service...
  [✓] routerd.service reloaded successfully.
Setup completed successfully for family: qwen
$ syntropctl models
MODEL                        STATUS     SIZE         PARAMS     BACKEND      CONTEXT   
------------------------------------------------------------------------------------
qwen2.5:0.5b                 cached     397.66 MiB   0.5B       -            8192      
llama3.2:1b                  cached     1.24 GiB     1.2B       -            8192      
qwen2.5-coder-7b             loaded     4.48 GiB     7.0B       cpu-avx2     32768     

CAS Storage Quota: 6.12 GiB / 64.00 GiB (9.6% utilized) • 3 models (1 pinned)

5. syntropctl drift [UNIT]

Inspect system configuration modifications and chronological audit logs.

CHRONOLOGY
$ syntropctl drift --since 1h
TIME (UTC)         SUBSYSTEM   TARGET FILE / UNIT                       EVENT TYPE
04:51:30 (12m ago) contextd    /etc/nginx/nginx.conf                    CONFIG_MODIFIED
04:50:12 (13m ago) rpm-ostree  openssl-libs (3.0.7 -> 3.2.0)            PKG_UPGRADE
04:12:05 (51m ago) toold       /etc/systemd/system/redis.service.d/     DROPIN_RESTORED

6. routerctl [SUBCOMMAND] & Wire Ingress Verification

Inspect dynamic routing decisions, test upstream LLM providers, and verify wire proxying on port 32768.

ROUTING

routerd provides reverse proxy wire ingress on TCP port 32768 and Unix domain socket /run/syntrop/router.sock. Operators manage routing policies, test upstream providers, and verify model reachability using routerctl and standard HTTP utilities.

Verify Wire Ingress via curl

Verify that routerd is listening on port 32768 and responds to OpenAI-compatible model enumeration:

$ curl http://127.0.0.1:32768/v1/models
{
  "object": "list",
  "data": [
    {
      "id": "router:fast",
      "object": "model",
      "created": 1758784000,
      "owned_by": "syntropd-router"
    },
    {
      "id": "router:hard",
      "object": "model",
      "created": 1758784000,
      "owned_by": "syntropd-router"
    },
    {
      "id": "qwen2.5-coder-7b",
      "object": "model",
      "created": 1758784000,
      "owned_by": "runtimed-local"
    }
  ]
}

Inspect Router Status & PSI Pressure

$ routerctl status
● routerd.service - Intelligent Model Router and Wire Protocol Gateway
     Status: OPERATIONAL (Uptime: 1h 45m)
     Wire Ingress: 127.0.0.1:32768, /run/syntrop/router.sock
     Varlink IPC:  /run/syntrop/io.syntrop.Router1
     Memory RSS:   8.42 MiB (MemoryHigh: 24M, MemoryMax: 32M)
     Kernel PSI:   Memory 0.0% some (normal)
     Providers:    3 configured, 3 healthy

List and Test Configured Providers

$ routerctl providers list
PROVIDER ID       KIND     TIER    STATUS    WEIGHT   LATENCY    MODELS
runtimed-local    runtimed fast    HEALTHY   1.0      12.4ms     qwen2.5-coder-7b
lan-runtimed      runtimed fast    HEALTHY   0.8      48.2ms     gemma4:e2b, qwen2.5:7b
local-vllm        openai   hard    HEALTHY   0.9      62.1ms     qwen3:32b
$ routerctl test runtimed-local
[TEST] Probing provider 'runtimed-local' at unix:/run/syntrop/io.syntrop.Runtime1...
[OK] Provider response received in 14.2ms.
[OK] Health check passed: HTTP 200 OK (models: 1, state: ready)

Simulate Routing Decisions

$ routerctl route --model router:fast --tokens 1024
ROUTING DECISION CANDIDATES:
  1. runtimed-local / qwen2.5-coder-7b  [SCORE: 96.4] Speed: 98.0  Cost: 100.0  Cap: 90.0  (Selected)
  2. lan-runtimed / gemma4:e2b          [SCORE: 81.2] Speed: 72.0  Cost: 100.0  Cap: 75.0
  3. local-vllm / qwen3:32b             [SCORE: 64.8] Speed: 42.0  Cost: 30.0   Cap: 99.0

7. Seven Architectural Frontiers Reference

Operator commands and API parameters for grammar decoding, speculative decoding, agent loops, reasoning budgets, infinite streaming context, multimedia pipelines, and dynamic memory governance.

FRONTIERS

1. Constrained JSON Grammar Decoding

Force model generation to adhere strictly to JSON schemas or Varlink payload syntax using SIMD-accelerated logit masking:

$ varlinkctl call /run/syntrop/io.syntrop.Runtime1 io.syntrop.Runtime1.Generate
varlinkctl call unix:/run/syntrop/io.syntrop.Runtime1 io.syntrop.Runtime1.Generate \
  '{"model":"qwen2.5:0.5b","prompt":"Emit error report:","grammar_type":"json","grammar":"{}","max_tokens":128}'

2. Heterogeneous Speculative Verification

Gang-schedule a CPU draft model (e.g. qwen2.5:0.5b) with a GPU target model (e.g. qwen2.5:7b) for 2x–3x generation acceleration:

$ varlinkctl call /run/syntrop/io.syntrop.Runtime1 io.syntrop.Runtime1.Generate
varlinkctl call unix:/run/syntrop/io.syntrop.Runtime1 io.syntrop.Runtime1.Generate \
  '{"model":"qwen2.5:7b","speculative_draft_model":"qwen2.5:0.5b","prompt":"Analyze cgroup freeze:","max_tokens":256}'

3. Reasoning Budget & Wire Think Filter

Specify reasoning token limits via OpenAI-compatible HTTP ingress, streaming reasoning chains separately from final content:

$ curl http://127.0.0.1:32768/v1/chat/completions
curl -N -s http://127.0.0.1:32768/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "router:fast",
    "reasoning_budget": 256,
    "stream": true,
    "messages": [
      {"role": "user", "content": "Triage degraded disk I/O on /var/log"}
    ]
  }'

4. Infinite Context StreamingLLM

Streaming journal monitoring runs 24/7 with pinned attention sinks and sliding FIFO windows in SinkWindowCache, preserving bounded RAM.

5. Multimedia Audio & Visual Generation

Generate real-time audio streamed to PipeWire or synthesize 1-step SD-Turbo visuals via isolated Varlink compute leases:

$ varlinkctl call /run/syntrop/io.syntrop.Runtime1 io.syntrop.Runtime1.StreamAudioOut
varlinkctl call unix:/run/syntrop/io.syntrop.Runtime1 io.syntrop.Runtime1.StreamAudioOut \
  '{"text":"System alert: cgroup CPU throttling exceeded threshold","voice":"af_heart","rate":24000}'

6. Dynamic Memory Telemetry & Leases

Query DRM device watermark levels and inspect dynamic memory leases:

$ varlinkctl call /run/syntrop/io.syntrop.Inference1 io.syntrop.Inference1.GetDrmWatermark
varlinkctl call unix:/run/syntrop/io.syntrop.Inference1 io.syntrop.Inference1.GetDrmWatermark \
  '{"device":"renderD128"}'

7. Accelerated Hardware Pipeline (Marlin GEMV, Ada Lovelace FP8 & Paged KV)

runtimed incorporates an ultra-fast hardware acceleration pipeline featuring:

Automated Unit Triage with systemd Drop-ins

Configure any mission-critical systemd service to automatically trigger AI-driven triage on failure.

Add a standard systemd drop-in file to your service (e.g. /etc/systemd/system/app.service.d/triage.conf):

/etc/systemd/system/app.service.d/triage.conf
[Unit]
# OnFailure automatically invokes the syntrop-triage template unit passing the failed unit name (%n)
OnFailure=syntrop-triage@%n.service

When app.service enters the failed state, systemd PID 1 starts syntrop-triage@app.service.service:

/usr/lib/systemd/system/syntrop-admin@.service
[Unit]
Description=syntropd Autonomous OS Self-Healing & Remediation for %I
Documentation=https://syntropd.github.io/manual.html
After=syntrop-sockets.target sentry.service toold.service contextd.service

[Service]
Type=oneshot
User=syntrop-admin
Group=syntrop
ExecStart=/usr/bin/syn admin remediate %I
StandardOutput=journal
StandardError=journal
SyslogIdentifier=syntrop-admin

# Systemd Sandboxing
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
Section 7

Autonomous OS Self-Healing & Administration

syn admin operates as the front door for autonomous self-healing, declarative remediation recipes, and circuit-breaker lockout safety across the subsystem.

Autonomous Administration CLI (`syn admin`)
# Inspect autonomous healing readiness and circuit-breaker states
syn admin status

# Execute or simulate a guided remediation recipe
syn admin remediate nginx.service --recipe restart --dry-run
syn admin remediate nginx.service

# Roll back configuration modifications from remediation snapshots
syn admin rollback nginx.service

# Inspect structured journald forensic audit records
syn admin audit --limit 50 --unit nginx.service --json

# Manually reset circuit-breaker lockout after operator inspection
syn admin lockout reset nginx.service
Section 8

Linux Cognitive Desktop Companion

syn companion delivers multimodal visual reasoning, automated UI action planning, and virtual desktop automation. It combines zero-disk screencast capture via io.syntrop.Sensory1, zero-disk multimodal streaming over routerd (/run/syntrop/router.sock), and guarded virtual HID actuation via io.syntrop.Actuator1 with automated physical input preemption.

Desktop Companion CLI (`syn companion`)
# Ask a grounded visual question about the active screen
syn companion ask "Explain what is causing the compilation error in the active terminal"

# Plan and execute desktop UI actions via virtual HID actuator
syn companion execute "focus terminal and run cargo check" --dry-run
syn companion execute "click the submit button"

# Run daemonized ambient listening session for voice or hotkey triggers
syn companion listen --voice --hotkey "Super+Space"

# Manage systemd user unit
systemctl --user status syntrop-companion.service
systemctl --user enable --now syntrop-companion.service
Systemd User Unit Configuration (`syntrop-companion.service`)
[Unit]
Description=syntropd Linux Cognitive Desktop Companion
Documentation=https://syntropd.github.io/manual.html
PartOf=graphical-session.target
After=graphical-session.target

[Service]
Type=simple
ExecStart=/usr/local/bin/syntropctl companion listen
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=syntrop-companion

# Sandboxing (GEMINI.md pure systemd-native)
PrivateTmp=true

[Install]
WantedBy=graphical-session.target
Section 9

Closed-Loop Kernel Telemetry & Dynamic PSI Tuning

syn telemetry and syn tune (backed by syntropctl telemetry) provide real-time zero-allocation kernel Pressure Stall Information (PSI) ingestion and eBPF scheduler latency telemetry, driving closed-loop dynamic throttling and speculative decoding governors across the subsystem.

Kernel Telemetry & Dynamic Tuning CLI (`syn telemetry`, `syn tune`)
# Inspect instantaneous kernel PSI pressure and eBPF runqueue latency
syn telemetry status
syn telemetry status --json

# Query or adjust closed-loop dynamic tuning governor policy
syn tune --policy balanced
syn tune --policy aggressive
syn tune --policy conservative

# Manage the systemd governor unit
systemctl status syntrop-tuning.service
Systemd Governor Unit Configuration (`syntrop-tuning.service`)
[Unit]
Description=syntropd Dynamic Kernel Telemetry & Closed-Loop Tuning Governor
Documentation=https://syntropd.github.io/manual.html
After=syntrop-sockets.target
PartOf=syntrop-sockets.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/syntropctl telemetry tune --policy balanced
CapabilityBoundingSet=CAP_BPF CAP_PERFMON CAP_SYS_RESOURCE
AmbientCapabilities=CAP_BPF CAP_PERFMON CAP_SYS_RESOURCE
ProtectSystem=strict
ConfigurationDirectory=syntrop
ReadWritePaths=/run/syntrop
SyslogIdentifier=syntrop-tuning

[Install]
WantedBy=multi-user.target

Dynamic Telemetry Architecture

The kernel telemetry architecture operates with zero heap allocations during steady-state polling: