Every Binions daemon runs as its own locked-down system user, supervised by systemd. There is no single “Binions” process and no shared account. Each background service gets a dedicated user, its own files, and a hardened systemd unit — so a problem in one daemon stays contained to that one daemon. This page explains that model and the everyday commands you use to manage the services.
Set this once, then forget it. The users, directories, and hardened units are created for you by the package when you
apt installa daemon. You normally only need thesystemctlcommands further down this page.
Each Binions daemon is a small background service — we call them daemons — and each one runs under its own dedicated system user. The user is always named after the service it belongs to, with an svc suffix: the logger daemon runs as loggersvc, the mailbox daemon as mailboxsvc, the playbook daemon as playbooksvc, and so on.
These are system users, not people. They are created with no password, no home directory, and no login shell — equivalent to:
useradd --system --no-create-home --shell /usr/sbin/nologin loggersvcThat means nobody can log in as one of these accounts, and they exist only to own and run their daemon. Each service user owns just its own slice of the filesystem:
/opt/binions/<service>/, owned by that service’s user./var/log/binions/<service>/, owned by that service’s user, with directory mode 0750 (only the owner and its group can read).redis:redis.Here are a few of the daemons and the users they run as. The pattern is always the same, so you can predict any user’s name from its service:
| Daemon | Runs as user |
|---|---|
| logger | loggersvc |
| mailbox | mailboxsvc |
| playbook | playbooksvc |
| scheduler | schedulersvc |
| webhookcaller | webhookcallersvc |
| database | databasesvc |
Why one user each. Isolation and least privilege. Because each daemon can only touch its own files and runs as an account that can do nothing else on the system, a compromised or misbehaving daemon cannot read another daemon’s secrets, tamper with its logs, or take over the host.
Every daemon is managed by systemd as a service named binions-<service>.service — for example binions-logger.service or binions-mailbox.service. The units are Type=notify, so systemd knows a daemon is truly ready (not just started), and each one ships with a strict security profile baked in. You don’t configure any of this — it is part of the package — but it is worth knowing what it buys you:
NoNewPrivileges=yes) — the daemon and anything it spawns can never gain more permissions than it started with.ProtectSystem=strict) — the daemon cannot write anywhere on the host except its own designated directories.CapabilityBoundingSet) — the daemon is granted only the handful of kernel privileges it genuinely needs and nothing more.MemoryDenyWriteExecute=yes) — a common path for injecting malicious code is closed off.SystemCallFilter) — the daemon may only make the system calls it actually uses; anything else is blocked by the kernel.Together, these make each daemon run with the least privilege it needs. In practice that means a far smaller attack surface than a typical service that runs as root with full access to the machine.
You manage Binions daemons with the standard systemctl commands. Every daemon has a paired Redis service named redis-binions-<service>.service — the daemon’s private event-bus instance — so you usually act on the pair together. Replace <service> with the daemon name (for example logger).
Enable and start a daemon and its Redis — turns it on now and on every boot:
sudo systemctl enable --now binions-<service> redis-binions-<service>Check a daemon’s status — shows whether it is active, its recent log lines, and any errors:
systemctl status binions-<service>Restart a daemon — for example after changing its configuration:
sudo systemctl restart binions-<service>Stop and disable a daemon — turns it off now and stops it starting at boot (do the same for its Redis if you want it fully off):
sudo systemctl disable --now binions-<service> redis-binions-<service>See which Binions services are running — lists the state of every daemon and its Redis at once:
systemctl is-active 'binions-*.service' 'redis-binions-*.service'The Redis pairing. Each daemon carries its own Redis instance for the internal event bus. If a daemon starts but behaves oddly, check that its
redis-binions-<service>partner is running too.
Because every daemon runs under systemd, all of its output goes to the system journal. To read a single daemon’s logs, point journalctl at its unit:
journalctl -u binions-<service>Add -f to follow the log live, or -e to jump to the most recent entries:
journalctl -u binions-<service> -fFor routine status and readiness checks beyond the logs, and for deeper day-to-day operations, see Health checks and systemd operations.