Linux systemctl Service Stuck in "activating (start-exec)" State

A service permanently stuck showing "activating (start-exec)" means systemd is waiting for the service's start process to signal that it's fully ready, but that signal is never arriving — this is very commonly caused by a mismatch between the service's declared Type and what the actual program does, or a hanging ExecStartPre step that never completes.

The Problem

Checking a service's status shows it perpetually in a starting state, never transitioning to fully active:

systemctl status your-service
● your-service.service
   Loaded: loaded
   Active: activating (start-exec) since ...

This state persists indefinitely rather than resolving to either "active (running)" or "failed" within any reasonable time.

Why It Happens

The "start-exec" sub-state specifically means systemd has launched the service's main process (or an ExecStartPre step) and is waiting for it to either complete (for simpler service types) or explicitly signal readiness (for Type=notify services). Common reasons this waiting never resolves:

• A service declared with Type=notify, but the actual program was never written to (or configured to) call sd_notify(READY=1) — systemd waits indefinitely for this specific readiness signal that the program will simply never send, since it doesn't implement this systemd-specific notification protocol at all
• An ExecStartPre command that hangs — waiting on a network resource, a file lock, or another condition that never resolves — blocking the entire startup sequence from ever proceeding to the actual main service start
• A service configured with Type=forking (expecting the initial process to fork into the background and the parent to exit) where the program doesn't actually fork the way systemd expects, so systemd keeps waiting for a parent-process-exit signal that will never come

The Fix

First, identify exactly what systemd is waiting for by checking the service's configured Type directive:

systemctl show your-service.service -p Type

If it's set to notify, confirm the actual program genuinely implements the sd_notify protocol — check its own documentation, since not every program that seems like a good fit for Type=notify actually implements this specific systemd integration:

# Check systemd unit file
cat /etc/systemd/system/your-service.service

If the program doesn't actually support sd_notify, change the service type to something that matches its actual behavior, most commonly simple (systemd considers the service started as soon as the main process launches, without waiting for any additional readiness signal):

[Service]
Type=simple

sudo systemctl daemon-reload
sudo systemctl restart your-service

If an ExecStartPre command is the actual source of the hang, test that specific command manually, in isolation, to confirm whether it genuinely completes or hangs indefinitely on its own:

# Extract the exact ExecStartPre command from the unit file and run it manually
sudo -u service-user /path/to/exec-start-pre-command

If this manual test also hangs, the fix needs to address that specific command's own underlying issue (a network dependency that isn't ready, a file lock held by something else) rather than anything about the service's own Type configuration.

For Type=forking services where the underlying program doesn't actually fork the way systemd expects, either correct the Type to match the program's actual real behavior (often simple, if the program just runs in the foreground without forking at all), or, if the program does fork but via a different mechanism than systemd's default expectation, specify the correct PID file location so systemd can correctly track the forked process:

[Service]
Type=forking
PIDFile=/var/run/your-service.pid

Still Not Working?

If the service type is confirmed correct and no ExecStartPre command is hanging when tested manually, but the service still gets stuck in this state, check the service's actual process with ps to confirm whether the underlying program process is genuinely running (even if systemd doesn't yet consider it "active") — if the process is running normally and functioning, but systemd simply never recognizes it as ready due to a genuine configuration mismatch, the service may actually be working from an application-functionality standpoint despite systemd's own status display being stuck, which at least clarifies that the priority fix is specifically correcting systemd's own understanding of the service's state, not the underlying application itself failing to start.