Problem: crontab jobs report command not found / wrong environment —— Trove problem library

What you will run into

A crontab scheduled job reports command not found / wrong environment once it runs:

# The job calls node (installed via nvm), conda, or a custom script; the log has one line:
/bin/sh: 1: demo-node: not found

Signs: the command clearly works in an interactive terminal (which node returns something), but cron execution says command not found; or the job runs but can't read env vars (NVM_DIR, CONDA_PREFIX, custom exports);

the cron log only has one line /bin/sh: N: xxx: not found with no more clues.

Common with: tools installed via nvm/conda/pyenv, vars exported in ~/.bashrc, environments that only exist in login shells.

Why this happens

The shell cron uses to run jobs has a completely different environment from your interactive terminal:

• cron runs commands with /bin/sh, which doesn't load ~/.bashrc, ~/.profile, or /etc/profile — nvm/conda/pyenv initialization (all written in ~/.bashrc) is entirely missing;
• The job's PATH is decided by the cron daemon: traditional SysV cron defaults to /usr/bin:/bin, not including /usr/local/bin, let alone nvm/conda custom directories;
• Counter-intuitive measurement (this machine, Ubuntu 26.04): when systemd starts cron -f -P, jobs inherit systemd's PATH (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin) — so /usr/local/bin is actually available;
• The real victims are paths and variables that are "only added in .bashrc", like ~/.nvm/versions/.../bin and conda environment directories;
• Aliases: also not effective in the cron environment.

Deterministic takeaway: "command not found / env var empty" in cron does not mean the system is broken. It means that command is not on cron's PATH.

Three correct paths:

• Export PATH explicitly at the top of the script, or use absolute command paths (/usr/bin/python3).
• Put the needed initializations inside the script itself.
• Run bash -lc in the cron line to emulate a login environment — closest to a terminal, but brings terminal env uncertainty.

To debug, log the job with * * * * * cmd >> /tmp/cron.log 2>&1 and inspect what the job actually sees.

Fixed diagnostic: it works manually but fails under cron = an environment difference, not a script logic problem.

Step by step

1. Confirm the job's environment first — Required

Temporarily put printenv > /tmp/cron-env.txt 2>&1 into the job and run once to see PATH and vars - much faster than guessing; or read the cron daemon environment directly: tr '\0' '\n' < /proc/$(pgrep -x cron)/environ | grep PATH.

2. Fix A: declare PATH at the top of the crontab — Required

PATH=... as the crontab's first line lets the job use relative command names.

3. Fix B: use absolute paths in the job — Required

~/.nvm/versions/node/v20/bin/node /path/script.js

Doesn't depend on PATH; most robust.

4. Fix C: load the environment inside the job — Required

. "$HOME/.bashrc" && mycmd

Note .bashrc usually has non-interactive guards; more robust is writing what you need into a standalone env file and doing . /path/env.sh && mycmd in the job.

5. Debugging tip — Required

Redirect job output to a log (>> /tmp/job.log 2>&1); on failure the xxx in the first line is the command whose path/vars you need to add.

How to confirm it works

The job runs normally (measured output shape):

After declaring PATH in the crontab -> job log outputs NODE-OK <time> (measured)
Absolute-path version -> also runs normally (measured)

Other environments

Symptom

A crontab scheduled job reports command not found / wrong environment:

# The job calls node (nvm-installed), conda, or a custom script; the log has one line:
/bin/sh: 1: demo-node: not found

Signs: the command works in an interactive terminal (which node has a result), but cron execution says command not found; or the job runs but can't read env vars (NVM_DIR, CONDA_PREFIX, custom exports); the cron log only has one line /bin/sh: N: xxx: not found; common with nvm/conda/pyenv-installed tools, vars exported in ~/.bashrc, environments needing a login shell.

Cause

The shell cron uses to run jobs has a completely different environment from your interactive terminal:

• cron runs commands with /bin/sh, not loading ~/.bashrc, ~/.profile, /etc/profile - nvm/conda/pyenv initialization (all in ~/.bashrc) is missing;
• The job's PATH is decided by the cron daemon: traditional SysV cron defaults to /usr/bin:/bin, not including /usr/local/bin, let alone nvm/conda custom directories;
• Counter-intuitive measurement (this machine, Ubuntu 26.04): with systemd starting cron -f -P, jobs inherit systemd's PATH (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin) - /usr/local/bin is actually usable; the real victims are paths/vars like ~/.nvm/versions/.../bin and conda environment directories that are "only added in .bashrc";
• Aliases: also not effective in the cron environment.

Solution

1. Confirm the job's environment first: temporarily put printenv > /tmp/cron-env.txt 2>&1 into the job and run once to see PATH and vars - faster than guessing; or read the cron daemon environment directly: tr '\0' '\n' < /proc/$(pgrep -x cron)/environ | grep PATH.
2. Fix A: declare PATH at the top of the crontab (most common): PATH=~/.nvm/versions/node/v20/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin as the crontab's first line; the job can then use relative command names.
3. Fix B: use absolute paths in the job: ~/.nvm/versions/node/v20/bin/node /path/script.js - doesn't depend on PATH, most robust.
4. Fix C: load the environment inside the job: * * * * * . "$HOME/.bashrc" && mycmd (note .bashrc usually has non-interactive guards; more robust is writing what you need into a standalone env file and doing . /path/env.sh && mycmd in the job).
5. Debugging tip: redirect cron job output to a log (>> /tmp/job.log 2>&1); on failure the xxx in the first line /bin/sh: N: xxx: not found is the command whose path/vars you need to add; after fixing, run again and confirm normal output in the log.