systemd-failed-to-start: causes and fixes for startup errors

What the systemd-failed-to-start Error Means

The Failed to start status is a general status that systemd assigns to a service (unit) when its startup process exits with a non-zero exit code, exceeds a specified timeout, or encounters a critical issue during initialization. In the output of the systemctl status command, it appears as:

● some-service.service - Some Service Description
   Loaded: loaded (/etc/systemd/system/some-service.service; enabled; vendor preset: enabled)
   Active: **failed** (Result: exit-code) since Thu 2026-02-15 10:30:00 MSK; 1min 30s ago
  Process: 1234 ExecStart=/usr/bin/some-service (code=exited, status=1/FAILURE)

Key flags: Active: failed and Result: exit-code (or timeout). This error blocks the service from running and can prevent the system from booting if the unit is critical.

Common Causes

The causes are specific and technical:

1. Invalid unit configuration file (.service). Errors in the [Service] section (incorrect path in ExecStart, ExecStartPre), [Install] section, or syntax.
2. Insufficient permissions. The service attempts to read/write to a directory it lacks access to (e.g., /var/log/app/), or runs under the wrong user (User=).
3. Resource conflicts. The port is already in use by another process, insufficient memory (OOM Killer), or file descriptor exhaustion.
4. Unmet dependencies. Services specified in Requires= or After= failed to start or exited with an error.
5. Corrupted application binary or dependencies. The file specified in ExecStart is missing, corrupted, or cannot load required libraries.
6. Timeout exceeded. The application takes too long to respond to initialization requests, and systemd kills it after TimeoutStartSec= (default 90 seconds) expires.

Resolution Methods

Method 1: Analyzing Service Logs with journalctl

This is the first and most crucial step. systemd logs contain detailed program output.

1. Find the exact service name (e.g., nginx.service).
2. Run the command to view logs for the current boot:

   journalctl -u nginx.service -b --no-pager
   

3. Carefully review the last 20-30 lines. Look for keywords Failed, Error, (code=exited, status=...), Permission denied, No such file or directory.
4. If the log is extensive, filter by error level:

   journalctl -u nginx.service -b -p err --no-pager
   

💡 Tip: Add the -e flag to jump to the end of the log immediately, or -f to follow in real-time while restarting the service.

Method 2: Verifying and Fixing the Configuration File

Errors in the unit file are a common cause.

1. Locate the service file:

   systemctl status nginx.service | grep Loaded
   # Output: Loaded: loaded (/etc/systemd/system/nginx.service; enabled; ...)
   

2. Check the syntax:

   sudo systemd-analyze verify /etc/systemd/system/nginx.service
   

   The command will show the line with an error if present (e.g., "Invalid command 'Execstar', not part of a unit configuration").
3. Open the file in an editor (sudo nano /etc/systemd/system/nginx.service) and check:
   • Paths in ExecStart, ExecStartPre: do they exist? (which some-binary or ls -la /path/to/file)
   • Permissions on the executable (ls -l /usr/bin/some-binary — should be -rwxr-xr-x).
   • The [Service] section: are User= and Group= correct? Does that user/group exist?
   • The WorkingDirectory= directive: does the directory exist?
4. After making corrections, run:

   sudo systemctl daemon-reload
   

Method 3: Checking Dependencies and Port/Resource Conflicts

1. Check if the port is in use (for network services):

   sudo ss -tulpn | grep :80  # Replace 80 with your service's port
   

   If the port is occupied by another process, find and stop it or change the port in the service config.
2. Check if all required services are running:

   systemctl list-dependencies nginx.service --reverse
   

   This shows which services depend on nginx. Ensure they are in active (running) state.
3. Check for available resources:

   free -h        # Memory
   df -h /var     # Disk space (especially for logs)
   ulimit -n      # File descriptor limit (might be too low)
   

   A shortage of any resource can cause the service to fail at startup.

Method 4: Reinstalling from Package or Manual Reinstall

If the service was installed via a package manager (apt, dnf, yum), its configuration might be corrupted.

1. Debian/Ubuntu:

   sudo apt update
   sudo apt install --reinstall nginx  # Replace nginx with the package name
   

   This restores files from /usr/share/doc/nginx/examples/ or original configs in /etc/.
2. RHEL/CentOS/Fedora:

   sudo dnf reinstall nginx
   

3. After reinstalling, do not overwrite your custom settings in /etc/nginx/nginx.conf (if any) if the package manager prompts. Compare the old and new unit configuration files (/lib/systemd/system/nginx.service vs /etc/systemd/system/nginx.service). Often, it's better to copy your changes into the new original file rather than using the old corrupted one.

Prevention

• Always check the syntax of both the service configuration file and the application's own config (e.g., nginx -t) before reloading systemd.
• Use systemctl daemon-reload after any change to a unit file in /etc/systemd/system/ or /lib/systemd/system/.
• Configure reasonable timeouts (TimeoutStartSec=, TimeoutStopSec=) for long-running services to avoid false positives.
• Monitor permissions on directories the service uses (/var/log/, /var/lib/, /run/). Creating a dedicated user/group for each service is recommended.
• Periodically check logs for warnings (journalctl -u <service>.service -p warning) before they escalate into errors.

Method N: Rollback to Previous Working Configuration (if using Git)

If service configuration files are under version control (a good practice):

1. Determine when the service last worked:

   sudo journalctl -u nginx.service -b --no-pager | grep -i "started\|failed"
   

2. Find the commit after which failures began:

   cd /etc/systemd/system/
   git log --oneline -p -- nginx.service
   

3. Temporarily restore the previous version of the file:

   sudo git checkout <commit_hash> -- nginx.service
   sudo systemctl daemon-reload
   sudo systemctl restart nginx.service
   

4. If this helped, analyze which specific changes broke the service and implement them more carefully.

Method N+1: Running the Service Manually for Debugging

Sometimes systemd obscures the actual error output. Run the executable directly as the same user the service runs under.

1. Find the user from the unit file (User=) or from the logs.
2. Execute:

   sudo -u <user> /usr/bin/some-service --verbose
   # Or, if the service runs a script:
   sudo -u <user> /bin/bash -x /path/to/startup-script.sh
   

   Flags like --verbose or -x (for bash) provide detailed output. The error often becomes obvious when running manually.