TL;DR: Cron may use a shorter PATH than your terminal; set the lab entry to call /usr/local/bin/serverlab-task by its absolute path.
The problem
A command can work when you type it in a terminal and still fail when cron runs it. This tutorial reproduces that behavior on a disposable Ubuntu 24.04 lab, then fixes the scheduled entry by using the script’s absolute path.
The script writes a timestamp to an output file. The cron entry also captures standard output and standard error in a log, so the failure is easy to inspect. Treat the example paths as belonging to the lab setup; avoid using a disposable exercise as a change to a production crontab.
Why it happens
Your interactive terminal and cron do not necessarily search the same directories for commands. In this example, the cron entry sets PATH to /usr/bin:/bin, while the script is installed in /usr/local/bin. When cron tries to run the bare command serverlab-task, it cannot find it.
The fix is to keep the lab entry’s PATH as shown and call the script using its absolute path. That tells cron exactly which file to run.
Step-by-step fix
- Create the lab directory and script file:
mkdir -p ~/serverlab-cron
sudo nano /usr/local/bin/serverlab-task
Put these exact lines in /usr/local/bin/serverlab-task:
#!/bin/sh
date -Is >> "$HOME/serverlab-cron/output"
Save and exit the editor. Then make the script executable and run it manually:
sudo chmod 755 /usr/local/bin/serverlab-task
serverlab-task
cat ~/serverlab-cron/output
The output should contain a timestamp, for example:
2026-10-25T12:00:08+00:00
- Open your user crontab:
crontab -e
Add this one lab entry:
* * * * * PATH=/usr/bin:/bin serverlab-task >> "$HOME/serverlab-cron/cron.log" 2>&1
The entry runs every minute and appends both standard output and standard error to cron.log. Wait for the next minute, then check the time and log:
date -Is
cat ~/serverlab-cron/cron.log
The log should show an error like this:
/bin/sh: 1: serverlab-task: not found
- Edit the crontab again:
crontab -e
Replace the bare-command entry with this absolute-path entry:
* * * * * PATH=/usr/bin:/bin /usr/local/bin/serverlab-task >> "$HOME/serverlab-cron/cron.log" 2>&1
Save and exit. For this walkthrough, skip waiting and inspect the output file:
date -Is
cat ~/serverlab-cron/output
A newer timestamp shows that cron ran the script. Timestamps, IP addresses, PIDs, and session numbers shown in examples are placeholders where relevant; use the values from your own system.
- Remove the temporary lab entry when you are done:
crontab -e
Delete the lab entry, then save and exit.
How to verify
The manual run should have written a timestamp to ~/serverlab-cron/output. The first cron attempt should have logged serverlab-task: not found. After changing the entry to /usr/local/bin/serverlab-task, a newer timestamp in the output file is evidence that the scheduled script ran.
For example, the output file may contain:
2026-10-25T12:00:08+00:00
2026-10-25T12:02:03+00:00
The exact timestamps will differ on your machine.
Common mistakes
- Assuming cron inherits the same
PATHas your interactive terminal. - Fixing the wrong crontab: make sure you edit the same user crontab used for the lab entry.
- Replacing the entry but forgetting to save and exit the editor.
- Reading
cron.logas proof of success after the fix; the script writes its timestamp tooutput. - Leaving the temporary lab entry in the crontab after the walkthrough.
If you want a clean Ubuntu box to practice on, PowerVPS is a reasonable choice: https://powervps.net/?from=32
Watch more fixes on Server Lab: https://www.youtube.com/channel/UCov7rfWAnS4c2wF5E9V1Yag
Top comments (0)