Dennis HilkLinux Fix LabDE

Services & systemd

A notify service never becomes ready

The process exists but Type=notify remains activating until its deadline. Check readiness messages, sender attribution and blocked initialization work.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • The unit stays activating for the startup interval.
  • systemd terminates it at the deadline even though the process exists.

Relevant environment

systemd services using Type=notify or notify-reload; the application must implement readiness notification.

Recognizable messages (synthetic examples)
systemd[1]: example.service: start operation timed out. Terminating.

Other service types can produce this too; verify Type=notify before readiness-specific changes.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • READY=1 may be absent or sent by a process excluded by NotifyAccess.
  • A migration, blocked lookup or unavailable dependency may prevent real startup completion.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace the unit name; no state transition is requested.

systemctl show example.service -p Type -p NotifyAccess -p TimeoutStartUSec -p MainPID -p SubState

Interpret the result: Type=notify waits for readiness. NotifyAccess=main accepts the main process; wrappers and children can change attribution.

Check 2

Read the affected unit's journal; administrative read permission may be needed.

journalctl -b -u example.service -o short-monotonic --no-pager -n 100

Interpret the result: Compare progress with the deadline. An application serving requests without notifying differs from one stuck during migration.

Evidence-guided next steps

Match the program's supported service type

If the application lacks notify support, use its documented service type, such as exec for a foreground program where supported. If notify is implemented, correct the wrapper or sender attribution so actual readiness reaches systemd.

Precautions: Leaving notify removes its readiness guarantee for dependent units. Never announce readiness before initialization completes.

Recovery / rollback: Restore Type and NotifyAccess, reload the definition and restart when interruption is acceptable.

Did this solution help you?

Share this solution#

Allow measured initialization time

If startup is progressing but takes longer than the finite deadline, choose an appropriate TimeoutStartSec or use application-supported EXTEND_TIMEOUT_USEC notifications. Resolve blocked prerequisites before increasing time.

Precautions: More startup time can delay boot and deployments. It does not repair a permanent hang.

Recovery / rollback: Restore the previous timeout and application configuration; compare another startup with the saved timeline.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.