Check a systemd unit before systemd ignores it.

35 checks over a real parse of the file, in four groups. Structure: an invalid section header, a lower-cased [unit], an unknown or repeated section, a line with no "=", an assignment written before the first section. Names: a directive in the wrong section (User= in [Unit]), a typo systemd throws away (ExecStrat=), a deprecated name, a name it simply does not know. Values: an enum that is wrong because systemd compares those case-sensitively, a non-boolean boolean, an Exec* path that is not absolute, shell syntax in an Exec* line that systemd will not interpret, an unknown % specifier, and an end-of-line "comment" that is really part of the value. Semantics: a service with no ExecStart=, two ExecStart= lines when Type is not oneshot, Type=forking with no PIDFile=, Restart=always with Type=oneshot, a timer with no trigger, an OnCalendar= systemd cannot parse, Persistent= on a monotonic timer, a socket with nothing to listen on, a missing [Install], and a system target in a user unit.

No, and it cannot be. systemd-analyze verify runs on a machine that has systemd, needs root for anything in the system search path, and — crucially — resolves the unit against THAT machine: the users, the paths, the drop-ins, the other units. That makes it the more thorough tool and the wrong tool for the moment you actually want the check: reviewing a .service in a pull request on a macOS laptop, or sanity-checking a unit an assistant just wrote for you. This reads one file as text, in your browser, and is explicit about the difference — everything it cannot know from the text alone is listed on this page rather than guessed at.

No. The parser and all 35 checks are JavaScript running in your tab — there is no server, no API call and no logging, so 0 bytes are uploaded. That matters here: unit files carry internal hostnames, private paths, service account names, EnvironmentFile= locations and occasionally a credential someone should not have put in a value.

The commonest cause by far is an OnCalendar= that systemd cannot parse, because cron syntax was pasted into it. Two forms account for nearly all of it. First, a bare "*/15": a systemd calendar repeat needs an explicit start value, so "*-*-* *:00/15:00" (or the shorter "*:00/15:00") is accepted and "*/15" is rejected outright. Second, a whole five-field crontab schedule ("0 3 * * *"): systemd calendar events are "DOW YYYY-MM-DD HH:MM:SS", not five fields, and this tool recognises the shape and sends you to the converter. After that, look for a timer with no trigger at all, and for a .timer with no Unit= whose matching .service has a different basename. A unit systemd refuses to load never appears in systemctl list-timers, which is why nothing looks wrong.

Because the setting does not take effect at all. systemd reads WantedBy= only from [Install]; anywhere else it logs "Unknown key name 'WantedBy' in section 'Unit', ignoring." and moves on. The unit loads, starts by hand, looks healthy — and systemctl enable silently does nothing, so it never comes back after a reboot. On this page an error means systemd refuses the unit OR discards the setting entirely; a warning means the setting applies and is a trap. A dropped setting belongs in the first group, because the file no longer describes what the machine will do.

Because this page ships a directive table — 439 names — and your machine ships a systemd. New directives arrive with every release, so a name this table has not heard of may be perfectly valid where you are going to run it. Calling that an error would train you to ignore the whole report, which is the one thing a linter cannot survive. A name that is a near-miss of a real directive is different: there the evidence is strong enough to say systemd is throwing the line away, and that IS reported as an error with the correction.

Three things, all about which manager will load the file. In user scope, a WantedBy= naming a system target (multi-user.target, graphical.target) is flagged: the user manager has no such target, so systemctl --user enable has nothing to link and the unit never starts — default.target is what you want, and timers.target does exist there. The scope also travels in the share link, so a link you send reproduces the findings you saw rather than a different set. Everything else — the parse, the names, the values — is identical, because systemd reads the file the same way either way.

It reads exactly one file, so: a template is parsed normally and %i is flagged as a note (it only has a value when the file is name@.service started as name@instance.service); a drop-in fragment is parsed fine on its own, but nothing here knows what it is overriding, so a partial file will look like it is missing an ExecStart=; and a unit named in After=, Wants= or Unit= is never resolved, because that file is not in front of us. Guessing at any of the three would be a confidently wrong answer, which is worse than no answer.

Up to 200,000 characters, which is roughly four thousand lines — two orders of magnitude past any real unit file. Past that it refuses with a message instead of freezing your tab, because an input that big is a journal dump, not a unit. Findings are capped too, at 20 per check and 200 in total, and the panel states the cap and the real count whenever one applies. The results list is capped separately at 50 rows per severity, again with the real number shown.