When a daemon won’t come up, work through these checks in order — the cause is almost always something the logs name plainly. Each Binions daemon is a systemd service that depends on its own Redis instance (and, in two cases, on an external database), so a daemon that refuses to start is usually waiting on a dependency, tripping over a bad config line, or being blocked by a port that is already in use. This page walks the checks from cheapest to deepest.
Naming reminder. The systemd unit is
binions-<name>, not<name>-service. Runningsystemctl status playbook-servicefails with “unit not found” — usesystemctl status binions-playbook. The same pattern applies to every daemon.
Don’t guess — start by reading what systemd and the daemon itself reported. The status line tells you whether the unit failed, is waiting on a dependency, or is in a restart loop; the journal shows the real error message right before it stopped.
systemctl status binions-<name> # current state + last lines
journalctl -u binions-<name> -n 100 --no-pager # the recent log, including the errorA climbing restart counter confirms a crash loop rather than a one-off:
systemctl show -p NRestarts --value binions-<name>Every daemon keeps its working state in a dedicated Redis instance and declares Requires / After on it. If that Redis is down, the daemon cannot start. Each one has its own unit, named to match:
systemctl status redis-binions-<name>
systemctl start redis-binions-<name> # the daemon follows once its Redis is upThis is the single most common cause of a daemon that won’t boot, so check it before anything deeper. More detail lives in Database & Redis problems.
binions-database connects to an external database engine — PostgreSQL, MySQL, MongoDB, or SQL Server, depending on your configuration — and binions-playbook depends on binions-database. If either refuses to start and Redis is healthy, confirm that your configured database server is running and reachable. For SQLite no external server is needed.
# Example: confirm the database process is active (adjust for your engine)
systemctl status postgresql # or mysqld, mongod, mssql-server, etc.Every other daemon reaches the database through binions-database, so this check is irrelevant to them. For connection-string and permission details, see Database & Redis problems.
A malformed application.toml stops the daemon at startup with a configuration error that names the offending key or line. The journal from step 1 will show it. Fix the file and restart:
systemctl restart binions-<name>Each daemon binds a loopback health and metrics port. If something else already holds that port, startup fails with a bind error in the log. Find and stop the conflicting process (often a previous instance that didn’t exit cleanly), then restart the daemon.
By default, the boot-time licence check is advisory — daemons log a warning about a missing or mismatched licence but still start. If enforcement has been turned on, a bad licence will block startup instead. If the journal points at the licence rather than a dependency, see License & activation problems.
The watchdog and READY signalling. A healthy daemon signals
READYto systemd only after it has started its event consumers and its health server — so “active” really does mean it is working. After that, systemd’s watchdog expects a heartbeat roughly every 30 seconds; if a daemon hangs and stops sending one, the watchdog restarts it automatically.