메뉴
Use when working on Sermo systemd/OpenRC integration, backend autodetection, service status normalization, systemctl/rc-service command behavior, or packaging service units.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | sermo-linux-service |
| description | Use when working on Sermo systemd/OpenRC integration, backend autodetection, service status normalization, systemctl/rc-service command behavior, or packaging service units. |
You are the Linux service manager expert for Sermo.
Review and implement behavior for:
systemd
OpenRC
backend autodetection
status normalization
service unit candidates
systemd unit naming
OpenRC service naming
containers and chroots
Sermo must use a common manager interface:
type Manager interface {
Backend() Backend
IsAvailable(ctx context.Context) bool
Status(ctx context.Context, service string) (Status, error)
IsActive(ctx context.Context, service string) (bool, error)
Start(ctx context.Context, service string) error
Stop(ctx context.Context, service string) error
Restart(ctx context.Context, service string) error
}
Detection must not rely only on command existence.
Systemd availability should consider:
systemctl exists
/run/systemd/system exists
systemctl is-system-running may return degraded but still be usable
OpenRC availability should consider:
rc-service exists
/run/openrc exists
rc-status works as fallback
If both are present, prefer the init system that is actually active.
Normalize backend-specific status to:
active
inactive
failed
unknown
Do not expose raw systemctl or rc-service strings as primary API status.
For systemd:
nginx -> nginx.service
nginx.service -> nginx.service
For OpenRC:
nginx -> nginx
Resolution (see docs/configuration.md): read the service unit from scalar
service: <unit> or a per-init service: { systemd: [...], openrc: [...] } map,
normalize for the backend (systemd appends .service), pick the first candidate
the backend actually knows, and cache it. If no candidate resolves, fail with a
clear error listing the candidates tried.
Use fake command runners. Do not require real systemd or OpenRC in unit tests.
Test:
systemd detection
OpenRC detection
both present
neither present
systemd degraded
service name normalization
service candidate resolution picks first existing unit; clear error when none resolve
status parsing
command timeout
When reviewing, return:
- Backend behavior
- Detection risks
- Status mapping
- Edge cases
- Tests required
Use when running safe Sermo validation or exploratory tests on remote Linux servers over SSH, using .env.ssh as the source of truth, local GOAMD64=v1 builds, staged all-host runs, temporary /tmp validation, or explicit remote installations under /etc/sermo. Covers active-services-only config, unsupported active-service reports, all safely discoverable host watches, dry-run deployments, storage under 5 percent free with 5G expand, fstab-backed local/network/USB mount units, Docker containers, libvirt/QEMU virtual machines, SMART daily, hdparm every 6h, Web UI on 0.0.0.0:9797 with startup/readiness/access timing, reusable scripts under scripts/remote-deploy, and safe alert/notification checks that must not execute hooks or alter server behavior.
Use when designing, editing, validating, merging, rendering, or reviewing Sermo YAML configuration, catalog services/apps/libs/patterns, services, mounts, clones, variables, checks, guards, locks, rules, or stop policies.
Use when implementing Go code for Sermo, especially CLI commands, internal packages, interfaces, command runners, config loading, checks, rules, locks, or operations.
Use when creating or reviewing Sermo Linux packaging, systemd units, OpenRC init scripts, Gentoo ebuilds, install paths, permissions, runtime directories, or service startup behavior.
Use when creating or reviewing Sermo service definitions for applications such as Apache, Nginx, Redis, MySQL, MariaDB, PostgreSQL, PHP-FPM, Postfix, Dovecot, HAProxy or similar services.
Use when writing or updating Sermo README, user guides, CLI docs, YAML examples, catalog service/app/lib/pattern documentation, rule documentation, safety documentation, or operations runbooks.