Files
computer-playbook/roles/sys-service/tasks/main.yml
kevinveenbirkenbachandClaude Opus 5 99f7e03845 feat(sys-service): carry unit ordering, an Install section and a user scope
The generic unit template could express neither an ordering dependency nor an Install section, so a role needing either shipped its own templates/systemctl.service.j2 and re-answered the daemon reload, the enable and the flush behaviour by hand.

Add After, Before, Wants, RemainAfterExit and a WantedBy driven Install section, all inert at their defaults, and route the unit path, its owner, become and the systemctl probes through a system_service_scope so a per-login unit lands under the user's own systemd directory.

00_core is gated on the system scope rather than only its prune and lockdown steps: it sets run_once_sys_service, so a user-scope caller running first would otherwise skip the lockdown for every system-scope role behind it in the same play.

Rendering the previous template against the same inputs drops no directive and adds none; the only difference is the blank line an empty directive used to leave behind.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-15 18:09:43 +02:00

20 lines
615 B
YAML

---
- name: "🔄 Reload sys-daemon handlers"
include_tasks: utils/load/handlers.yml
vars:
handler_role_name: "sys-daemon"
when: run_once_sys_service is defined
- include_tasks: 00_core.yml
when:
- run_once_sys_service is not defined
- system_service_scope == 'system'
- name: "▶️ Execute service routines for '{{ system_service_id }}'"
block:
- name: "🧩 Load base routine for '{{ system_service_id }}'"
include_tasks: 04_base.yml
- name: "🚿 Flush system service handlers for '{{ system_service_id }}'"
meta: flush_handlers
when: system_service_id is defined