Synopsis #
A command that works in a terminal can fail under cron because it runs as another account, depends on shell startup files, uses relative paths, or expects an interactive prompt. Put the operation in a small script, run it as the intended account, and capture its output before choosing the final schedule.
The example records the date and home-filesystem space. Replace /home/alice with the intended account’s actual home directory throughout. Run the unprivileged commands as that account.
Prepare a command that works without a terminal #
Create a private script directory if necessary:
$ mkdir -p "$HOME/bin"
Save this as $HOME/bin/record-status:
#!/bin/sh
set -eu
PATH=/bin:/usr/bin
export PATH
cd /home/alice
/bin/date -u
/bin/df -h /home/alice
Make it executable and test with an explicit environment:
$ chmod 0755 "$HOME/bin/record-status"
$ env -i HOME="$HOME" PATH=/bin:/usr/bin SHELL=/bin/sh /bin/sh "$HOME/bin/record-status"
This is a useful environment check, but the scheduled run remains the final test. Add /usr/local/bin or /usr/local/sbin to the script’s PATH when it uses packaged commands. Password prompts, graphical sessions, and interactive shell aliases are unsuitable dependencies for an unattended job.
Add a per-account crontab entry #
Inspect the existing schedule, then edit it:
$ crontab -l
$ crontab -e
no crontab for ... means that no per-account table exists yet. Preserve existing entries. Add this temporary once-per-minute check, ending the line with a newline:
* * * * * /home/alice/bin/record-status >> /home/alice/status.log 2>&1
A per-account entry has five time fields followed by the command. Do not insert a username between the schedule and command. /etc/crontab and files under /etc/cron.d or /usr/local/etc/cron.d use the different system format, which includes that username field.
Confirm the saved entry:
$ crontab -l
The daemon notices changes made by crontab; restarting cron is unnecessary.
Verify the scheduled result #
After the next minute boundary, inspect the output:
$ tail -n 20 "$HOME/status.log"
The file should contain a new date and filesystem report. Check its owner and the command’s result, rather than treating installation of a crontab as proof that the job ran.
If nothing appears, an administrator can check the daemon and its log:
# service cron status
# tail -n 50 /var/log/cron
Check that the account is usable, the script is executable, its interpreter exists, and the account can read its inputs and write the log. Cron uses /bin/sh for the command line by default; it does not run an interactive login shell. An unescaped % in the command field also has special meaning in crontab(5), even inside shell quotes. Put commands using date format strings in the script instead.
Choose the final schedule #
Use crontab -e to replace the temporary entry with the intended frequency, or remove that entry after testing. Do not use crontab -r to remove one job: it removes the account’s entire table.
Redirecting output to a file requires a rotation or retention plan. Without redirection, cron normally mails command output; that is useful only when local operational mail reaches a monitored mailbox. See Choose a mail server or an outgoing relay .