Your shell finds a snap command but a systemd service cannot, and snapd-env-generator is usually the reason. This guide verifies that snapd's systemd environment generator adds /snap/bin to the manager's PATH, then reloads systemd so newly started services can use it. Allow about ten minutes. The checks are read-only; the reload is a manager-wide configuration action and needs elevated privileges.
This guide uses snapd 2.76.3+ubuntu24.04 on the local machine. The installed manual describes snapd-env-generator as an internal tool, not as a command for installing or running snaps. Treat its location and output as integration details owned by systemd.
Find the package version and the generator path first:
$ dpkg-query -W -f='${Package} ${Version}\n' snapd
snapd 2.76.3+ubuntu24.04
$ ls -l /usr/lib/systemd/system-environment-generators/snapd-env-generator
-rwxr-xr-x 1 root root ... /usr/lib/systemd/system-environment-generators/snapd-env-generator
On another distribution, the directory may differ. The useful rule is that systemd loads system environment generators from a directory whose name ends in system-environment-generators. Do not copy a path from this example without checking your package contents.
Checkpoint: the file must exist and be executable. If it is missing, check that the installed snapd package is complete before changing any profile or shell startup file.
The generator reads the current environment and prints a replacement assignment only when it needs to extend PATH. Give it a temporary test value that does not already contain /snap/bin:
$ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
/usr/lib/systemd/system-environment-generators/snapd-env-generator
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
The output is an environment assignment for systemd to parse. It does not change the calling shell, edit /etc/profile or start snapd. The generator exits successfully without printing an assignment when /snap/bin is already present:
$ PATH=/usr/local/sbin:/usr/bin:/snap/bin \
/usr/lib/systemd/system-environment-generators/snapd-env-generator
$ printf '%s\n' "$?"
0
Do not mistake that empty output for a failure. It means there is no new value for this generator to add.
Adding a directory to a systemd manager environment does not rewrite the environment of an existing terminal. A shell that was opened before the change keeps its own PATH. Check both contexts separately:
$ printf '%s\n' "$PATH" | tr ':' '\n' | grep -x /snap/bin
/snap/bin
If the shell check prints nothing, that only says this shell lacks the directory. Open a new login session or use the shell startup configuration supplied by your distribution, then check again. Do not add several competing PATH lines just because a service has a different environment.
For a systemd service, the relevant environment is the manager's environment plus the unit's own settings. The generator therefore helps services started after the manager has loaded its generated environment. It does not override an explicit Environment=PATH=... in a unit or repair a command whose path is wrong.
After installing the package, restoring the generator, or masking it accidentally, ask systemd to rerun its generators:
$ sudo systemctl daemon-reload
This is an elevated command because it asks the system manager to reload configuration. It does not restart every service, but units started afterwards can receive the regenerated environment. Avoid combining it with restart until you know which service needs restarting.
Verify the manager's exported environment without starting a service:
$ systemctl show-environment | grep '^PATH='
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin
Your existing manager may contain additional directories. The check is successful when the PATH assignment includes /snap/bin, not when it matches this line character for character.
Use a harmless status or environment inspection before changing the unit:
$ systemctl show --property=Environment example.service
Environment=
An empty unit-specific Environment property does not prove that the manager environment is absent. If the service still cannot find a snap command, inspect its effective process environment and logs, then check for a unit-level PATH override:
$ systemctl cat example.service
$ journalctl -u example.service -b --no-pager | tail -n 30
Replace example.service with the real unit name. These commands only read configuration and recent logs. If the unit contains an explicit, incomplete Environment=PATH=..., fix that unit deliberately and preserve any directories it actually needs. Do not edit the generated generator output by hand.
If the generator is present but the manager's PATH lacks /snap/bin, check whether a higher-priority generator with the same name masks it, or whether a later generator replaces PATH. Inspect the generator directories and the unit's own configuration before changing files:
$ ls -l /run/systemd/system-environment-generators \
/etc/systemd/system-environment-generators \
/usr/local/lib/systemd/system-environment-generators \
/usr/lib/systemd/system-environment-generators 2>/dev/null
$ systemctl show-environment | grep '^PATH='
A symlink to /dev/null can mask a generator. Removing a mask is a privileged, state-changing operation, so confirm the cause and keep a record of the original link before undoing it. If a service is already running, reloading systemd alone does not replace its environment. Restart only that service, during an approved maintenance window, after checking its unit and dependencies.
The manual's description is intentionally short: this program is run by systemd to ensure that the snap bin directory, usually /snap/bin, is in PATH. It has no documented options, profile arguments or enable switch. Do not use it as a substitute for snap, and do not assume that a visible directory means a particular snap is installed.
/snap/bin when it is absent and stays quiet when it is already present.systemctl daemon-reload was used only when systemd needed to rerun its generators.systemctl show-environment shows /snap/bin in the manager's PATH.PATH override before any restart.