Loading...

VONDS ©

Lab 148: User Crontab Workflow

Back to Lab Index

Configure user crontab entries using correct 5-field scheduling, control cron email behavior with output redirection and MAILTO, and verify the crontab helper’s setuid permissions so ordinary users can safely manage their own cron jobs.

services core troubleshooting

Scenario

You need to configure user cron jobs correctly, control email output behavior for scheduled tasks, and verify the crontab tool’s permissions so ordinary users can edit their own schedules without direct write access to cron spool files.

Operator context

Cron failures are often silent. Correct schedules, explicit output handling, and basic permission validation prevent “it ran but I never saw it” incidents.

Objective

  • Open or create your user crontab.
  • Write a correct schedule line for a weekly job.
  • Control cron mail behavior by redirecting standard output only.
  • Edit an entry to remove redirection cleanly.
  • Route all cron mail output to a specific user with MAILTO.
  • Verify the crontab binary’s permissions with ls -l.

Concepts

  • User crontab management with crontab -e .
  • Cron’s 5-field schedule format (minute, hour, day of month, month, day of week).
  • Output and mail behavior: cron emails any output produced by the job unless redirected or suppressed.
  • Redirecting only stdout with >> file so stderr is still mailed.
  • Using MAILTO=... to route cron mail for the entire crontab.
  • Why /usr/bin/crontab is commonly setuid root (writes into protected cron spool areas).

Walkthrough

Step 1 : Open or create your user crontab.
Command 
crontab -e

This opens your personal crontab in an editor. On first use, it creates the file. You do not edit cron spool files directly. The crontab command handles safe installation.

Step 2 : Run date every Friday at 1:00 PM.
Crontab line 
0 13 * * 5 date

Minute 0 at hour 13 (1 PM), any day-of-month, any month, day-of-week 5 (Friday). This is the standard 5-field format for user crontabs.

Step 3 : Run foobar every minute, redirecting only stdout to a log.
Crontab line 
* * * * * ~/foobar.sh >> ~/output.log

>> appends standard output to the file. Standard error is not redirected here, so stderr still triggers cron mail. This is a useful pattern when you want a log for normal output but still want error visibility.

Step 4 : Remove the redirection from the foobar entry.
Crontab line 
* * * * * ~/foobar.sh

Removing redirection means any output (stdout or stderr) becomes eligible for cron mail delivery (subject to MAILTO). This is a common troubleshooting move when you suspect a job is failing silently.

Step 5 : Route all cron mail output to emma.
Crontab setting 
MAILTO=emma

Place MAILTO=emma near the top of the crontab. It sets the recipient for mail generated by any job output in that crontab.

Step 6 : Verify permissions on the crontab binary.
Command 
ls -l /usr/bin/crontab

Many systems ship crontab as setuid root so users can install their crontabs into protected spool directories. In a long listing, the setuid bit appears as an s in the user execute position. 

-rwsr-xr-x 1 root root  ... /usr/bin/crontab

Common breakpoints

crontab -e fails with “you are not allowed to use this program”

Check /etc/cron.allow and /etc/cron.deny policy on the system. If access is restricted, only approved users can create or edit crontabs.

Job runs but output is missing

Cron runs with a minimal environment. Use full paths, ensure the script is executable, and redirect output intentionally. If you redirected stdout, errors may still be mailed, and if mail is not configured you may see nothing.

MAILTO set but nobody receives mail

MAILTO controls the recipient, but mail delivery still depends on a working local MTA configuration. Confirm mail tooling is present and logs show successful delivery.

/usr/bin/crontab is not setuid

Behavior varies by distribution and policy. If the binary is not setuid, user cron management may rely on different mechanisms. Treat it as a configuration/policy check and verify how cron is implemented on that system.

Cleanup checklist

Remove test entries so you do not leave noisy schedules behind on shared lab hosts. You can either edit the crontab and delete the lines or clear the user crontab entirely.

Commands 
crontab -e
# OR (destructive: removes the entire user crontab)
crontab -r
Success signal

crontab -l shows only the entries you intend to keep, or nothing at all if you removed the crontab.

Reference

  • crontab -e : Opens your user crontab for editing.
    • -e : Edit (create if missing).
  • * * * * * <command> : Cron schedule format: minute hour day-of-month month day-of-week.
  • MAILTO=<user> : Routes cron mail for any job output to a specific user.
  • > file : Redirects stdout to a file (overwrite).
  • >> file : Redirects stdout to a file (append).
  • ls -l /usr/bin/crontab : Shows permissions and ownership for the crontab binary.
    • s : Setuid bit when shown in the user execute position (example: -rwsr-xr-x ).
  • crontab -l : Lists the current user crontab.
  • crontab -r : Removes the current user crontab.
    • -r : Remove (destructive).