What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The warning means systemd cannot treat the first token in ExecStart= (or a related command directive) as a usable executable. Put a real executable at the start—preferably its full absolute path—then reload the manager and restart the unit. Variables, shell built-ins such as exec, and shell-style quoting copied into a unit file are common causes of the parser failure.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What the warning actually means
systemd parses a service command before it attempts to start the process. The first token in ExecStart= must identify the program systemd is supposed to execute. On older systemd behavior, that token had to be an absolute path. If parsing fails, systemd can discard the command and leave the unit without a usable ExecStart; the service then never reaches the application-level startup checks.
As an Amazon Associate I earn from qualifying purchases.
One documented failure involved a quoted path containing a space:
ExecStart='/tmp/space bin'The parser reported Executable path is not absolute, ignoring: '/tmp/space bin'. The quotes did not turn the whole line into a shell command. They made the first token a path that systemd still rejected, so the unit ended up without a valid start command.
#1 Best Overall
A variable in the executable position has the same risk. For example, placing $CELERY_BIN first was recorded upstream as producing the warning. A variable is not a reliable executable token for this purpose; resolve the program to a path in the unit instead.
Inspect the unit systemd is really loading
Before editing anything, check the complete unit and every drop-in. A file in /etc/systemd/system may be overridden by a vendor unit, a generated file, or a drop-in directory.
-
Display the merged unit text, including drop-ins:
systemctl cat example.service -
Show the source file and drop-in paths:
systemctl show example.service -p FragmentPath -p DropInPaths -
Look for every
ExecStart=,ExecStartPre=,ExecStartPost=, andExecStop=line. The same executable-token rule can affect related command directives.
If the line you changed is not visible in systemctl cat, you edited the wrong file or a later drop-in is replacing it. Fix the file that is actually loaded, or remove the conflicting override.
Repair ExecStart= step by step
1. Find the installed executable
Resolve the command as the service manager should see it, rather than relying on the interactive shell used for administration.
command -v myapp
ls -l /usr/local/bin/myappcommand -v reports the path found in your current shell. Confirm the file exists and inspect its permissions with ls -l. If the command is installed somewhere else, use that actual location.
2. Put the absolute path first
Use a real executable as the first token and place options after it:
[Service]
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.ymlDo not put an assignment, a shell expression, or a descriptive command string before /usr/local/bin/myapp. An explicit path is the clearest choice across systemd releases and does not depend on the manager’s search path.
3. Reload the manager after editing
Editing a unit file does not automatically change the manager’s in-memory definition.
systemctl daemon-reloadThen restart and inspect both the unit state and its boot journal:
systemctl restart example.service
systemctl status example.service --no-pager
journalctl -u example.service -b --no-pagerIf the warning disappears but the service still fails, you have moved past the parser problem. Follow the execution checks later in this guide.
How to start scripts correctly
Call an interpreter explicitly
This is the most predictable form when the script is not executable or when you need to select an interpreter:
[Service]
ExecStart=/bin/bash /opt/myapp/start.shThe first token is the absolute path to Bash. The script is an argument, so it must be readable by the service’s user; it does not need its executable bit for Bash to read it.
Execute the script directly
Direct execution is also valid when the script is executable and begins with a valid shebang:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors[Service]
ExecStart=/opt/myapp/start.shCheck both conditions: the file must have execute permission for the service user, and the shebang must name an interpreter that exists on the machine. A script that works in an interactive shell can still fail under systemd if its interpreter, configuration, or working directory is unavailable to the service account.
Direct script versus interpreter invocation
| Choice | Interpreter selection | File requirements | Process and signal behavior |
|---|---|---|---|
| Absolute script path | Selected by the script’s shebang | Executable bit, valid shebang, and service-user access | The interpreter launched for the script becomes the service’s command process; child-process behavior still depends on the script |
/bin/bash /path/script.sh |
Forced to the stated Bash path | Script must be readable; executable bit is not required | Bash is the command process, which can change how signals and child processes are handled compared with a program that replaces itself |
Choose the explicit interpreter when the script’s shebang is missing, non-portable, or intentionally different from the host default. Choose direct execution when the shebang and permissions are part of the script’s contract and you want systemd to invoke that contract directly.
Why variables and shell built-ins fail in the executable position
Variables are not a substitute for the first executable token
This pattern is unsafe:
ExecStart=$MYAPP_BIN --config /etc/myapp/config.ymlThe parser must identify the executable before a shell expands environment variables. Put the resolved absolute path in ExecStart= instead. Environment settings can still be supplied for the application, but they should not be relied on to name the executable itself.
exec, source, and export are shell built-ins
These are not standalone programs that systemd can execute as the first token:
Rank #4
ExecStart=exec /usr/local/bin/myapp
ExecStart=source /etc/myapp/env
ExecStart=export MODE=productionIf the command genuinely needs shell grammar—such as conditional operators, pipelines, command substitution, or several shell assignments—invoke a shell by its absolute path and pass -c with the command as an argument:
ExecStart=/bin/bash -c 'command-that-needs-shell-syntax'This changes quoting rules and process behavior. The shell becomes the process systemd starts, so signal forwarding, exit status, and child reaping need to be considered. Do not use a shell merely to launch an ordinary binary; a direct absolute path is simpler and less error-prone.
Paths containing spaces
Unit command lines use systemd’s own command-line parsing. They are not copied verbatim to an interactive shell. Shell quoting that looks familiar can therefore create a malformed executable token, including the documented '/tmp/space bin' warning.
Keep the executable token unambiguous and quote or escape a path with spaces as an argument according to systemd’s unit-file rules. For example, when Bash is the executable and the script path is the second argument:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →ExecStart=/bin/bash "/opt/my app/start.sh"Here the absolute executable is /bin/bash; the quoted path is only an argument. Do not put the entire command, including its executable, inside one shell-style quoted string. After saving the unit, run systemctl daemon-reload and inspect systemctl status to verify that the manager accepted the resulting command line.
When possible, installing software under a path without spaces avoids an extra layer of escaping. If relocating the file is not an option, use systemd’s documented quoting and escaping syntax rather than pasting a command copied from a shell script.
Best Value
Absolute path or simple filename?
Systemd’s behavior has changed over time. Older documentation required an absolute path. Later documentation permits a simple filename without slashes and resolves it through a fixed search path. An absolute path remains the most portable and auditable form.
| Form | Portability across versions | PATH dependence | Maintenance trade-off |
|---|---|---|---|
ExecStart=/usr/local/bin/myapp |
Works with the older absolute-path requirement and newer releases | None for locating the executable | Must be updated if the program is moved |
ExecStart=myapp |
Requires a systemd version that accepts a filename without slashes | Resolved through the manager’s fixed search path | Survives a move within that search path, but can become ambiguous or unavailable |
Do not assume the PATH from your login shell applies to a system service. The documented system-manager PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin, which may differ from an interactive user’s PATH.
Free tools Windows power users keep installed
One-click scans. No signup required.
Systemd documents ExecSearchPath= as a colon-separated list of absolute directories used to locate executables; that setting was added in version 250. Because both the directive and filename resolution are version-sensitive, use a full path when a unit must be portable across distributions or releases.
When the parser accepts the line but startup still fails
Removing “Executable path is not absolute” only proves that systemd accepted the command syntax. The next failure may be unrelated. Check these conditions in order:
- Target exists: verify the exact path with
ls -l. A typo or a package removed during an upgrade produces a different failure. - Permission to execute or read: the service user needs execute permission on a binary or interpreter and read permission on a script and its supporting files.
- Shebang and interpreter: for direct scripts, confirm that the shebang names an installed interpreter and that every directory in the path is traversable.
- Configuration and working directory: relative paths that worked from a terminal may fail because the unit starts in a different directory. Use absolute configuration paths or set the unit’s working directory deliberately.
- Environment: a service does not automatically inherit your login shell’s variables, aliases, functions, or PATH.
- Sandbox and identity: restrictions, a non-root
User=, read-only paths, or filesystem protections can block an otherwise valid executable.
Use the three views together: systemctl cat shows the command actually configured, systemctl status shows the immediate result, and journalctl -u example.service -b supplies the detailed error from this boot. The original parser warning cannot identify any of these host-specific execution conditions.
A practical troubleshooting decision path
- Warning appears while loading: inspect the merged unit and find the first token of each command directive. Replace variables, shell built-ins, quoted command strings, and relative paths with a real absolute executable path.
- The warning is gone but the unit has no command: run
systemctl daemon-reload, then checksystemctl catagain for a replacement or conflicting drop-in. - The unit now starts and immediately exits: read the journal. Check script permissions, shebang, interpreter, configuration access, working directory, and service-user privileges.
- The command works in a terminal but not as a service: compare the manager’s fixed PATH and environment with the shell’s. Replace implicit lookups and relative paths with explicit values.
- A path contains spaces: ensure the absolute executable remains the first token and apply systemd’s own argument quoting or escaping to the later path. Reload and test rather than assuming shell syntax is equivalent.
Known-good patterns
Binary with options
[Service]
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.ymlScript with a selected interpreter
[Service]
ExecStart=/bin/bash /opt/myapp/start.shExecutable script with a shebang
[Service]
ExecStart=/opt/myapp/start.shShell syntax only when it is genuinely required
[Service]
ExecStart=/bin/bash -c 'command-that-needs-shell-syntax'In every pattern, systemd can identify the first token without expanding a variable or interpreting a shell built-in. That is the essential condition for eliminating this specific warning.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
