Service management
Controlling the service
- Linux (systemd)
- macOS
- Windows
systemctl status wakora-agent
systemctl restart wakora-agent
journalctl -u wakora-agent -f
On OpenRC use rc-service wakora-agent ..., on sysvinit /etc/init.d/wakora-agent ....
wakora service install
wakora service uninstall
sudo launchctl kickstart -k system/io.wakora.agent
.\wakora.exe service install
.\wakora.exe service uninstall
.\wakora.exe service start
.\wakora.exe service stop
service install is idempotent: if the service already exists it fixes the image path to
the current binary and starts it, which fixes the "installed from Downloads" trap.
Logs
The agent writes its own log to /var/log/wakora/agent.log (10 MB rotation to .old),
and also to the journal on systemd. On Windows the log lives under %ProgramData%\Wakora.
One-shot commands (--key, --test, secret) log to stderr only.
tail -f /var/log/wakora/agent.log
Resource budget
The agent is built to stay light: under 1% CPU and well under 100 MB of RAM at production
cadence. Measured across a production fleet at a 60-second interval it sits at 15 to 80 MB
of RSS: a quiet box stays near the bottom of that range, a host with hundreds of sites, APM
and log shipping near the top. It self-limits in process (GOMEMLIMIT 128 MiB, GOMAXPROCS capped at 2), and
the systemd unit adds CPUQuota=30%, Nice=10, and OOMScoreAdjust=500. That last one
means that under host memory pressure the kernel kills the agent before any client
service.
One deliberate non-limit: the unit sets no cgroup memory limit at all. A cgroup
memory limit counts the page cache of every file the process (and its helpers) reads,
so any finite limit on a busy host forces the kernel to evict the cache the agent just
filled and re-read it from disk every cycle. That turns a memory limit into constant
disk I/O (measured live, repeatedly: orders of magnitude difference, and even a
generous 1 GB ceiling reproduced it on a large host). The heap is capped in-process,
which is the limit that actually matters, and OOMScoreAdjust keeps the kill order
honest. An agent that finds itself under a finite limit, ours from an older install or
one set by hand, lifts it on its own service, live, through the service manager, and
says so in its log.
Uninstalling
wakora uninstall removes the agent completely (service, files, binary) and
deregisters the host. See Uninstalling.
Dry run
To see what the agent would collect without connecting:
wakora --test