# Member-requested process restarts (issue #113) — carlos-adopt.path's twin
# for the third half the sandboxed agent cannot do itself. The agent's
# serial poll sees the console's bump within ~2s, compares the app's restart
# generation, and bounces its OWN exec children immediately — but it cannot
# restart a systemd unit: not a carlos-app@ tenant, and not the bespoke unit an
# addr-backed route names (issue #110's consoles). Touching
# /data/restart-requested relays that to a root pass.
#
# It starts carlos-restart.service — `carlos adopt -restart-only` —
# deliberately NOT carlos-adopt.service or carlos-config-sync.service. A
# restart request changes no version and writes no config, so a full pass would
# stage releases and nag about canaries on a per-request trigger, and the
# config pass would find no changed env file and cycle nothing at all. Same
# split, and the same reason, as carlos-stage.path having its own service.
#
# /data is hardcoded like every path in these unit files — a box with a
# nonstandard data dir simply never fast-triggers and keeps the hourly floor
# (carlos-adopt.timer runs the same comparison).
[Unit]
Description=CARLOS instance restart on agent request (carlos restart)

[Path]
PathChanged=/data/restart-requested
Unit=carlos-restart.service

[Install]
WantedBy=multi-user.target