skills$openclaw/linux-service-triage
kowl644.8k

by kowl64

linux-service-triage – OpenClaw Skill

linux-service-triage is an OpenClaw Skills integration for data analytics workflows. Diagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks. Use when a server app is failing, unreachable, or misconfigured.

4.8k stars7.5k forksSecurity L1
Updated Feb 7, 2026Created Feb 7, 2026data analytics

Skill Snapshot

namelinux-service-triage
descriptionDiagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks. Use when a server app is failing, unreachable, or misconfigured. OpenClaw Skills integration.
ownerkowl64
repositorykowl64/linux-service-triage
languageMarkdown
licenseMIT
topics
securityL1
installopenclaw add @kowl64/linux-service-triage
last updatedFeb 7, 2026

Maintainer

kowl64

kowl64

Maintains linux-service-triage in the OpenClaw Skills directory.

View GitHub profile
File Explorer
4 files
.
references
triage-commands.md
595 B
_meta.json
294 B
SKILL.md
3.1 KB
SKILL.md

name: linux-service-triage description: Diagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks. Use when a server app is failing, unreachable, or misconfigured.

Linux & service basics: logs, systemd/PM2, permissions, Nginx reverse proxy, DNS checks

PURPOSE

Diagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks.

WHEN TO USE

  • TRIGGERS:
    • Show me why this service is failing using logs, then give the exact fix commands.
    • Restart this app cleanly and confirm it is listening on the right port.
    • Fix the permissions on this folder so the service can read and write safely.
    • Set up Nginx reverse proxy for this port and verify DNS and TLS are sane.
    • Create a systemd service for this script and make it survive reboots.
  • DO NOT USE WHEN…
    • You need kernel debugging or deep performance profiling.
    • You want to exploit systems or bypass access controls.

INPUTS

  • REQUIRED:
    • Service type: systemd unit name or PM2 process name.
    • Observed symptom: error message, status output, or logs (pasted by user).
  • OPTIONAL:
    • Nginx config snippet, domain name, expected upstream port.
    • Filesystem paths used by the service.
  • EXAMPLES:
    • systemctl status myapp output + journalctl excerpt
    • Nginx server block + domain + upstream port

OUTPUTS

  • Default: triage report (likely cause, evidence from logs, minimal fix plan).
  • If explicitly requested and safe: exact shell commands to apply the fix. Success = service runs, listens on expected port, and reverse proxy/DNS path is correct.

WORKFLOW

  1. Confirm scope and safety:
    • identify service name and whether changes are permitted.
  2. Gather evidence:
    • status output + recent logs (see references/triage-commands.md).
  3. Classify failure:
    • config error, dependency missing, permission denied, port conflict, upstream unreachable, DNS mismatch.
  4. Propose minimal fix + verification steps.
  5. Validate network path (if web service):
    • app listens → Nginx proxies → DNS resolves → (TLS sanity if applicable).
  6. Provide restart/reload plan and confirm health checks.
  7. STOP AND ASK THE USER if:
    • logs/status output are missing,
    • actions require privileged access not confirmed,
    • TLS/cert management is required but setup is unknown.

OUTPUT FORMAT

TRIAGE REPORT
- Symptom:
- Evidence (what you provided):
- Most likely cause:
- Fix plan (minimal steps):
- Exact commands (ONLY if user approved changes):
- Verification:
- Rollback:

SAFETY & EDGE CASES

  • Read-only by default: diagnose from provided outputs; do not assume you can run commands.
  • Avoid destructive changes; require explicit confirmation for anything risky.
  • Prefer nginx -t before reload and verify ports with ss.

EXAMPLES

  • Input: “journal shows permission denied on /var/app/uploads.”
    Output: path permission analysis + safe chown/chmod plan + verification.

  • Input: “App works locally but domain returns 502.”
    Output: upstream port checks + nginx error log interpretation + proxy_pass fix plan.

README.md

No README available.

Permissions & Security

Security level L1: Low-risk skills with minimal permissions. Review inputs and outputs before running in production.

## PURPOSE Diagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks. ## WHEN TO USE - TRIGGERS: - Show me why this service is failing using logs, then give the exact fix commands. - Restart this app cleanly and confirm it is listening on the right port. - Fix the permissions on this folder so the service can read and write safely. - Set up Nginx reverse proxy for this port and verify DNS and TLS are sane. - Create a systemd service for this script and make it survive reboots. - DO NOT USE WHEN… - You need kernel debugging or deep performance profiling. - You want to exploit systems or bypass access controls. ## INPUTS - REQUIRED: - Service type: systemd unit name or PM2 process name. - Observed symptom: error message, status output, or logs (pasted by user). - OPTIONAL: - Nginx config snippet, domain name, expected upstream port. - Filesystem paths used by the service. - EXAMPLES: - `systemctl status myapp` output + `journalctl` excerpt - Nginx server block + domain + upstream port ## OUTPUTS - Default: triage report (likely cause, evidence from logs, minimal fix plan). - If explicitly requested and safe: exact shell commands to apply the fix. Success = service runs, listens on expected port, and reverse proxy/DNS path is correct. ## WORKFLOW 1. Confirm scope and safety: - identify service name and whether changes are permitted. 2. Gather evidence: - status output + recent logs (see `references/triage-commands.md`). 3. Classify failure: - config error, dependency missing, permission denied, port conflict, upstream unreachable, DNS mismatch. 4. Propose minimal fix + verification steps. 5. Validate network path (if web service): - app listens → Nginx proxies → DNS resolves → (TLS sanity if applicable). 6. Provide restart/reload plan and confirm health checks. 7. STOP AND ASK THE USER if: - logs/status output are missing, - actions require privileged access not confirmed, - TLS/cert management is required but setup is unknown. ## OUTPUT FORMAT ```text TRIAGE REPORT - Symptom: - Evidence (what you provided): - Most likely cause: - Fix plan (minimal steps): - Exact commands (ONLY if user approved changes): - Verification: - Rollback: ``` ## SAFETY & EDGE CASES - Read-only by default: diagnose from provided outputs; do not assume you can run commands. - Avoid destructive changes; require explicit confirmation for anything risky. - Prefer `nginx -t` before reload and verify ports with `ss`. ## EXAMPLES - Input: “journal shows permission denied on /var/app/uploads.” Output: path permission analysis + safe chown/chmod plan + verification. - Input: “App works locally but domain returns 502.” Output: upstream port checks + nginx error log interpretation + proxy_pass fix plan.

Requirements

  • OpenClaw CLI installed and configured.
  • Language: Markdown
  • License: MIT
  • Topics:

FAQ

How do I install linux-service-triage?

Run openclaw add @kowl64/linux-service-triage in your terminal. This installs linux-service-triage into your OpenClaw Skills catalog.

Does this skill run locally or in the cloud?

OpenClaw Skills execute locally by default. Review the SKILL.md and permissions before running any skill.

Where can I verify the source code?

The source repository is available at https://github.com/openclaw/skills/tree/main/skills/kowl64/linux-service-triage. Review commits and README documentation before installing.