Using it
Run it always-on
Prometheus in a terminal dies with the terminal. Installed as a service it starts at login, restarts when it falls over, and is there when Beacon or Telegram reaches for it — which is the point of a daemon rather than a chat window.
In the foreground, first
Before installing anything, run it by hand and watch it start. Problems are much easier to read here than in a journal.
oara daemon
One flag: --telegram-only starts just the Telegram adapter and nothing else,
which is occasionally useful for isolating a gateway problem from a daemon problem.
Leave it running and confirm from another shell on the same machine:
curl -s localhost:8005/health
An empty reply means nothing is listening — curl -s suppresses the
connection error, so a refused port and an empty response look identical. Drop the
-s if you want it to say so out loud.
Installing the service unit
oara install-service Wrote ~/.config/systemd/user/prometheus.service
| Flag | What it does |
|---|---|
--now | Start the service immediately after enabling it. |
--force | Overwrite an existing prometheus.service. Backs the old one up first. |
--systemd-dir DIR | Write somewhere other than ~/.config/systemd/user. |
install-service writes the unit, then runs systemctl --user
daemon-reload. Where there is no user bus — a container, a bare SSH session without
a login session — the reload fails, it prints
WARNING: systemctl --user daemon-reload failed, and the command exits
1. The unit file was still written. Check for the file before concluding
it failed, and run systemctl --user daemon-reload yourself once you have a
session that can.
What the unit actually contains
No mystery worth preserving — this is the file it writes, unedited:
[Unit] Description=Prometheus AI Agent Daemon After=network.target [Service] Type=simple ExecStart=~/.local/bin/oara daemon ExecStop=/bin/kill -SIGTERM $MAINPID Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal # Secrets (PROMETHEUS_API_TOKEN, gateway tokens, provider keys) live in # the env file, written by `oara setup` / `oara token rotate`. # The leading "-" makes it optional so a fresh install still boots. EnvironmentFile=-%h/.config/prometheus/env [Install] WantedBy=default.target
Three things in there are worth reading rather than skimming.
Restart=on-failure with RestartSec=10 means a crash comes back in
ten seconds but a clean exit stays down — stopping it deliberately does not fight you.
The leading - on EnvironmentFile makes the env file optional, so a
fresh install boots before you have written any secrets. And output goes to the journal,
not to a file, which is where to look when something fails at boot.
Running it
systemctl --user enable --now prometheus systemctl --user status prometheus systemctl --user restart prometheus systemctl --user stop prometheus
Two more worth knowing. loginctl enable-linger $USER keeps a user service
running after you log out — without it the daemon stops when your session ends, which is
usually not what "always-on" was supposed to mean. And a config change needs a restart: the
daemon reads its configuration at startup.
Logs
| Where | What |
|---|---|
journalctl --user -u prometheus -f | The service's stdout and stderr. Start here for anything about starting, crashing or restarting. |
~/.prometheus/logs/cli.log | Always gets INFO, even when the console is quieter. Start here for what the agent did. |
The console default in chat mode is WARNING deliberately, so a reply is not buried in
operator logging; -v raises it. The file does not change either way.
install-service writes a systemd user unit. On macOS there is no systemd and
this command has nothing to write to — you need a launchd agent, and Prometheus does not
generate one today. Until it does, running oara daemon under a process
manager you already trust is the honest answer.
Verifying it came up
Three checks, weakest to strongest. systemctl --user status prometheus says
the process is alive. curl -s localhost:8005/health says it is answering.
oara doctor says whether it is answering
correctly — config loaded, model reachable, token set, directories writable. Only
the third distinguishes running from working.