Exit Codes

Edit on GitHub

Exit codes

All Cognitora binaries follow the same exit-code convention so systemd, Kubernetes, and shell pipelines can react sensibly.

CodeMeaningExamples
0clean exitnormal SIGTERM shutdown after draining in-flight work
1generic failureruntime panic, unhandled error
2bad invocationunknown flag, malformed --config path
3configuration invalidcognitora.toml parse error or schema validation failure
4dependency unavailableetcd unreachable on startup, missing helm binary on PATH
5TLS / PKI errorcert/key mismatch, expired CA, missing client_ca_file
6engine failurecgn-agent: engine binary not found, ready probe never green
7port bind failureanother process is using [router].listen_http etc.
8storage errorcgn-kvcached: index dir not writable, SSD tier path missing
9feature unsupported--features rdma build needed but called on an unsupported OS
10gracefully drainedcgn-agent exited because cgn-ctl cluster drain finished
130SIGINTCtrl-C during interactive run
143SIGTERMnormal stop signal under systemd / Kubernetes

How to use this in systemd

The shipped units already declare:

Restart=on-failure
SuccessExitStatus=10 130 143

so a clean drain (10), a Ctrl-C (130), or a systemctl stop (143) won't trigger a restart, but a real crash (1) or a config error (3) will.

How to use this in Kubernetes

The Helm chart's Deployment spec uses terminationMessagePolicy: FallbackToLogsOnError so a non-zero exit plus the last log line lands in kubectl describe pod. Combined with the table above this gives a one-glance diagnosis.

Tests

rust/libraries/cgn-core/tests/exit_codes.rs exercises the matrix above against cgn_core::exit_code(&Error). Every binary's main() funnels its returned Error through that function before exiting, so the systemd SuccessExitStatus lists and the Kubernetes runbook stay in lockstep with the table above.