Dennis HilkLinux Fix LabDE

Services & systemd

WorkingDirectory prevents a service from starting

A unit can fail with 200/CHDIR before launching its program. Resolve missing mounts, traversal permissions and the directory visible inside its root.

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 service reports status=200/CHDIR.
  • The expected directory appears only after a mount or deployment step.

Relevant environment

systemd units with WorkingDirectory and optional RootDirectory or separate application mounts.

Recognizable messages (synthetic examples)
systemd[1]: example.service: Main process exited, code=exited, status=200/CHDIR

The failure precedes the application; inspect path visibility and access.

Possible causes

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

  • WorkingDirectory may reference a removed directory or the wrong path inside the service root.
  • Unavailable backing storage or denied traversal can prevent chdir before execution.

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; this reads effective settings.

systemctl show example.service -p WorkingDirectory -p RootDirectory -p RequiresMountsFor

Interpret the result: WorkingDirectory adds relevant mount dependencies automatically but does not create its directory. Compare it with RootDirectory.

Check 2

Replace the path with the configured host directory; no files are changed.

namei -l /srv/example/current

Interpret the result: A missing symlink target or inaccessible ancestor explains failure. Host visibility does not prove visibility inside the service root.

Evidence-guided next steps

Align the directory with deployment

If deployment moved, set WorkingDirectory to its actual path inside the service root. If the application needs no particular working directory, replace relative configuration and data references with explicit paths.

Precautions: Removing the setting can change which relative files are read. Preserve the old deployment symlink and unit.

Recovery / rollback: Restore the original WorkingDirectory and symlink, reload the unit and start when its path is available.

Did this solution help you?

Share this solution#

Provision the intended directory

If the path holds service state, provision it using StateDirectory or distribution configuration with the correct service owner. If data resides on a separate mount, repair that mount rather than merely creating an empty directory.

Precautions: An empty replacement directory can initialize a second dataset. Verify the expected mount source before starting.

Recovery / rollback: Revert provisioning, retain any newly written data separately and reconnect the original mount before restart.

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.