# systemd unit validator

- Human page: https://happytails.ai/en/developer-tools/systemd-unit-validator/
- Markdown: https://happytails.ai/en/developer-tools/systemd-unit-validator.md
- Structured JSON: https://happytails.ai/agents/en/developer-tools/systemd-unit-validator/index.json
- Visibility: public

## Tool capabilities

| Property | Value |
| --- | --- |
| Tool ID | `systemd-unit-validator` |
| Category | developer-tools |
| Implementation | Registered implementation. Registration alone is not a production-quality guarantee. |
| Browser execution | Use the visible action or interactive controls. |
| Browser processing | Browser; see tool notes for network behavior. |
| HTTP API | Not callable through HTTP. |
| Browser-agent interface | run_current_tool |

### Implementation notes

Checks systemd unit files and drop-ins on your device without loading them. Up to 500,000 characters and 200 files.

### Inputs and settings

Text input: Unit files.

Example or placeholder shown in the interface (not a validated fixture):

```text
[Unit]
Description=Web app

[Service]
ExecStart=/usr/bin/web
```

Paste one or more unit files. Start each file with ### file: and its name. Up to 500,000 characters. Review the settings before running.

| Setting | Meaning | Control type | Default | Constraints |
| --- | --- | --- | --- | --- |
| `version` | systemd version | select | "257" | Allowed: 257, 255, 252, 249, 245, 239 |
| `name` | File name when there is no ### file: line | text | "app.service" |  |

### Browser-agent workflow

1. Open the human page in a browser that supports WebMCP.
2. Discover the interface exposed by that page; use its actual schema.
3. Select files on the page first when the tool requires files.
4. Call `run_current_tool` with valid input and settings.
5. Inspect the returned result or error and the displayed output. Retrieve files from the displayed download links.

Calls do not automatically copy or download results. Browser permissions still apply. Interface availability alone is not proof of successful execution.

### Planning specification

Up to 500,000 characters, 200 files and 20,000 settings in one file. Everything runs on your device in a background worker and nothing is uploaded. Downloads: JSON report, CSV findings and an SVG dependency graph.

This describes intended requirements. Use the implementation notes, interface schema and observed output to determine current support.

### Complete machine-readable capability record

```json
{
  "id": "systemd-unit-validator",
  "category": "developer-tools",
  "built": true,
  "requirements": "Up to 500,000 characters, 200 files and 20,000 settings in one file. Everything runs on your device in a background worker and nothing is uploaded. Downloads: JSON report, CSV findings and an SVG dependency graph.",
  "implementation": {
    "fields": [
      {
        "key": "version",
        "label": "systemd version",
        "value": "257",
        "type": "select",
        "values": [
          "257",
          "255",
          "252",
          "249",
          "245",
          "239"
        ]
      },
      {
        "key": "name",
        "label": "File name when there is no ### file: line",
        "value": "app.service",
        "type": "text",
        "help": "For example web.service. Drop-ins are named like web.service.d/override.conf."
      }
    ],
    "registrationFamily": "config-directive-linters",
    "inputMaxLength": 500000,
    "inputErrorCode": "CONFIG_DIRECTIVE_LINTERS_TOO_LONG_SYSTEMD",
    "note": "Checks systemd unit files and drop-ins on your device without loading them. Up to 500,000 characters and 200 files.",
    "experience": {
      "automatic": false,
      "single": false,
      "inputMaxLength": 500000,
      "inputMode": "text",
      "label": "Unit files",
      "placeholder": "[Unit]\nDescription=Web app\n\n[Service]\nExecStart=/usr/bin/web",
      "help": "Paste one or more unit files. Start each file with ### file: and its name. Up to 500,000 characters. Review the settings before running.",
      "action": null
    },
    "mode": "explicit",
    "interactive": false
  },
  "execution": "Browser interface",
  "api": null,
  "browser_agent": {
    "supported": true,
    "name": "run_current_tool",
    "discovery": "WebMCP on the human page in a supporting browser",
    "verification": "See audit/API-AUDIT.md; availability is not verification"
  }
}
```

## Page guide

Check systemd unit files and drop-ins for unknown or misplaced settings, bad values, ExecStart mistakes and ordering cycles, and see how the units depend on each other.

How can we improve this tool?

Report a problem or share an idea.

Please leave out private information. Your message and the tool name go to our team via PostHog.

### How to use systemd unit validator

1. Paste unit files. Start each with ### file: and its name, such as ### file: web.service or ### file: web.service.d/override.conf.
2. Choose the systemd version your servers run.
3. Run the check and review each finding with its file and line.
4. Download the JSON report, CSV or the dependency graph image.

## Useful next steps

- [Environment file validator](https://happytails.ai/en/developer-tools/environment-file-validator/) ([Markdown](https://happytails.ai/en/developer-tools/environment-file-validator.md))

- [Cron parser](https://happytails.ai/en/developer-tools/cron-parser/) ([Markdown](https://happytails.ai/en/developer-tools/cron-parser.md))

- [TOML validator](https://happytails.ai/en/data-tools/toml-validator/) ([Markdown](https://happytails.ai/en/data-tools/toml-validator.md))

## What is checked

The settings table is written by Happytails.ai from the systemd 257 man pages (freedesktop.org, read on 16 October 2026) for \[Unit\], \[Install\], \[Service\], \[Socket\], \[Timer\], \[Path\], \[Mount\], \[Automount\], \[Swap\] and \[Slice\]. Values are checked as yes or no, time spans, numbers or fixed choices, and settings added after the version you choose are flagged. Older names that systemd still accepts, such as StartLimitBurst= in \[Service\] or ReadWriteDirectories=, are checked as the setting they stand for and noted.

### Drop-ins and dependencies

Drop-in files are merged after their unit in name order. List settings such as ExecStart= add up and an empty assignment clears them, which is how ExecStart overrides work. The tool then checks the rules systemd uses to refuse a service (ExecStart=, ExecStop=, SuccessAction= and RemainAfterExit=, at most one ExecStart= unless Type=oneshot, and no Restart=always or on-success for Type=oneshot), Exec prefixes, timer, socket and path triggers, mount unit names, and ordering cycles built from After= and Before=.

### Limits

systemd itself is not run, so files, users and implicit default dependencies are not checked and specifiers such as %i are not expanded. Settings outside the table are reported as unknown, the same way systemd logs and ignores them.