#966 Implementation of `service_commands` to issue service restarts in `osctrl-tls` from `osctrl-api` Pull request opened by javuto Summary • Added a DB-backed

service_commands

system so

osctrl-api

can request an

osctrl-tls

restart without shell, Docker, SSH, or systemd privileges. • Updated

POST /api/v1/service-config/apply

to be service-aware: •

api

keeps the existing local restart behavior. •

tls

creates a one-shot restart command for

osctrl-tls

. • Added

GET /api/v1/service-config/commands/{command_id}

so restart command status can be polled. • Updated

osctrl-tls

to poll for pending restart commands, consume them once, exit for supervisor restart, and mark consumed commands as recovered on startup. • Updated the frontend service config view to apply restarts for the selected service and display TLS restart command status. • Updated dev Air config so

osctrl-tls

restarts when it exits with code

1

. • Suppressed noisy idle polling logs by avoiding GORM

record not found

logging when no service command exists. Security • Restart commands are allowlisted to

target_service=tls

and

action=restart

. • No host-level process control was added to

osctrl-api

. • Restart apply remains protected by existing admin auth and rate limiting. • Command lifecycle is auditable through requested, consumed, expired, and recovered states. Validation •

GOCACHE=/tmp/osctrl-gocache go test ./pkg/servicecommands

•

GOCACHE=/tmp/osctrl-gocache go test ./pkg/servicecommands ./cmd/tls

•

GOCACHE=/tmp/osctrl-gocache go test ./pkg/servicecommands ./cmd/api/handlers ./cmd/api ./cmd/tls

•

npm test

•

npm run build

jmpsec/osctrl