systemd Service Failed to Start — Unit Activation Error and Debugging
About systemd Service Failed to Start
Fix systemd service startup failures by reading journal logs, understanding unit dependencies, and debugging ExecStart configuration issues. This guide covers everything you need to know about this topic, including common causes, step-by-step solutions, and answers to frequently asked questions.
Here are the key things to understand: systemd manages service lifecycle through unit files (.service) in /etc/systemd/system/ or /lib/systemd/system/. Service failures show as 'failed' in systemctl status and are logged in the journal. Common failure types: ExecStart binary not found, permission denied, dependency not met, crash after start. The journal (journalctl) contains detailed startup logs including stdout/stderr of the service process. Services have dependencies (Requires, After, Wants) that must be satisfied before starting. Understanding these fundamentals will help you diagnose and resolve this issue more effectively.
The most common reasons this occurs include: ExecStart path incorrect or binary not found at the specified path. Service user does not have permission to access required files or ports. Dependency service not running (e.g., database not started before the application). Application crashes immediately after starting due to configuration errors. Identifying the root cause is the first step toward finding the right solution.
To resolve this, follow these recommended steps: Check service status and error: 'systemctl status service-name.service' for overview. Read detailed logs: 'journalctl -u service-name.service -n 50 --no-pager' for last 50 log lines. Verify ExecStart path: 'which binary-name' or 'ls -la /path/to/binary' to confirm it exists and is executable. Test the command manually: run the ExecStart command directly as the service user to see errors. After fixing the unit file: 'systemctl daemon-reload' then 'systemctl start service-name'. If these steps do not resolve the issue, consider consulting additional resources or a qualified professional.
This article is part of our Linux Error Codes collection on Error Codes Wiki. We provide comprehensive, up-to-date information to help you find solutions quickly.
Quick Answer
Where should I put my custom service files?
Put custom service files in /etc/systemd/system/. Files in /lib/systemd/system/ are managed by packages and may be overwritten during updates. Run systemctl daemon-reload after creating or modifying unit files.
Overview
Fix systemd service startup failures by reading journal logs, understanding unit dependencies, and debugging ExecStart configuration issues.
Key Details
- systemd manages service lifecycle through unit files (.service) in /etc/systemd/system/ or /lib/systemd/system/
- Service failures show as 'failed' in systemctl status and are logged in the journal
- Common failure types: ExecStart binary not found, permission denied, dependency not met, crash after start
- The journal (journalctl) contains detailed startup logs including stdout/stderr of the service process
- Services have dependencies (Requires, After, Wants) that must be satisfied before starting
Common Causes
- ExecStart path incorrect or binary not found at the specified path
- Service user does not have permission to access required files or ports
- Dependency service not running (e.g., database not started before the application)
- Application crashes immediately after starting due to configuration errors
Steps
- 1Check service status and error: 'systemctl status service-name.service' for overview
- 2Read detailed logs: 'journalctl -u service-name.service -n 50 --no-pager' for last 50 log lines
- 3Verify ExecStart path: 'which binary-name' or 'ls -la /path/to/binary' to confirm it exists and is executable
- 4Test the command manually: run the ExecStart command directly as the service user to see errors
- 5After fixing the unit file: 'systemctl daemon-reload' then 'systemctl start service-name'