icon

InfoUnix

Linux · Solaris · DevOps

Solaris · Lesson

Solaris · Lesson 25

Crontab & at in Solaris

cron is used for recurring scheduled jobs; at is used for one-time jobs at a specific time. In this lesson, you'll learn when to use which, how to write crontab entries, and how to control which users are allowed to schedule jobs.

Add your crontab/at tutorial video URL in solarisLessons.js.

What are cron and at? When to use them?

In Solaris, cron and at are classic scheduling tools:

cron – recurring scheduler

Runs commands at specified times repeatedly (daily, weekly, monthly, every 5 minutes, etc.).

at – one-time scheduler

Runs a command once at a particular date/time (e.g. tonight 23:00, tomorrow 06:00).

Where to use cron

  • Daily/weekly backups
  • Log rotation scripts
  • Monitoring checks every N minutes
  • Maintenance tasks at fixed schedule

Where to use at

  • One-time maintenance job (e.g. patch cleanup tonight)
  • Run once after a change window
  • Schedule a restart later without staying logged in

When NOT to use cron/at

Avoid cron/at when

  • Job requires complex dependency handling → better use orchestration tools (e.g. Ansible, Jenkins).
  • Job is very long-running and already supervised by SMF/systemd.
  • Job needs high-availability clustering decisions.
  • You need centralized scheduling across many servers (better use enterprise scheduler).

Difference between cron and at (Solaris)

cron

  • Recurring jobs.
  • Defined in per-user crontab files.
  • Format driven by 5 time fields.
  • Managed via crontab -e/-l/-r.

at

  • Single-shot jobs.
  • Stored in at job queue.
  • Time specified in free-form format (06:00, now + 10 minutes).
  • Managed via at / atq / atrm.

Cron format, examples, allow/deny, and at usage

1. Difference between cron and at

Use cron for recurring jobs, at for one-time jobs at a specific time.

terminal — cron/at
solaris-lab
# Cron = recurring
# Example: Run a script every day at 02:30
[root@solaris ~]# crontab -e
30 2 * * * /usr/local/bin/backup.sh
 
# At = one-time
# Example: Run a script tomorrow at 06:00 once
[root@solaris ~]# at 06:00 tomorrow
/usr/local/bin/backup.sh
<Ctrl+D>
job 1 at Tue Jan 21 06:00:00 2025

2. Crontab format and placeholders

Each line has 5 time fields + command. Order: minute, hour, day-of-month, month, day-of-week, then command.

terminal — cron/at
solaris-lab
# * * * * * command
# | | | | |
# | | | | +-- day of week (0-6, 0 or 7 = Sunday)
# | | | +---- month (1-12)
# | | +------ day of month (1-31)
# | +-------- hour (0-23)
# +---------- minute (0-59)
 
# Examples:
# 1) Every minute
* * * * * /usr/local/bin/test.sh
 
# 2) Every day at 01:15
15 1 * * * /usr/local/bin/cleanup.sh
 
# 3) Every Monday at 03:30
30 3 * * 1 /usr/local/bin/report.sh
 
# 4) Every weekday at 09:00
0 9 * * 1-5 /usr/local/bin/daily.sh
 
# 5) Every 5 minutes
*/5 * * * * /usr/local/bin/check.sh

3. List and edit your own crontab

Each user has their own crontab file stored in /var/spool/cron/crontabs.

terminal — cron/at
solaris-lab
# Show current user's cron
[john@solaris ~]$ crontab -l
 
# Edit current user's cron (uses default editor)
[john@solaris ~]$ crontab -e
 
# Remove current user's crontab
[john@solaris ~]$ crontab -r

4. View/edit other user’s cron as root

Root (or privileged) can manage crontab for other users with -u.

terminal — cron/at
solaris-lab
# As root:
[root@solaris ~]# crontab -l -u oracle
 
[root@solaris ~]# crontab -e -u oracle
 
# On disk, user crons are under:
[root@solaris ~]# ls /var/spool/cron/crontabs
root oracle www john

5. Cron allow/deny configuration

Use cron.allow / cron.deny to control which users can use cron.

terminal — cron/at
solaris-lab
# Files (Solaris):
# /etc/cron.d/cron.allow
# /etc/cron.d/cron.deny
 
# Rules:
# - If cron.allow exists: only users listed in it may use cron.
# - If cron.allow does NOT exist but cron.deny exists:
# Users listed in cron.deny are denied; others allowed.
# - If neither file exists: usually only root can use cron (implementation dependent).
 
# Example:
[root@solaris ~]# cat /etc/cron.d/cron.allow
root
oracle
john
 
[root@solaris ~]# cat /etc/cron.d/cron.deny
guest
test

6. at allow/deny configuration

at uses similar allow/deny files, but for one-time jobs.

terminal — cron/at
solaris-lab
# Files:
# /etc/cron.d/at.allow
# /etc/cron.d/at.deny
 
# Same rule pattern as cron:
# - at.allow exists → only users listed can use at.
# - at.allow absent, at.deny exists → users listed are denied, others allowed.
# - None → typically only root.
 
[root@solaris ~]# cat /etc/cron.d/at.allow
root
oracle
 
[root@solaris ~]# cat /etc/cron.d/at.deny
guest

7. Using at for one-time jobs

at accepts natural time expressions like now + 10 minutes, 08:00, midnight, tomorrow etc.

terminal — cron/at
solaris-lab
# Schedule a job for tonight at 23:15
[root@solaris ~]# at 23:15
/usr/local/bin/nightly_backup.sh
<Ctrl+D>
job 2 at Mon Jan 20 23:15:00 2025
 
# Schedule a job 10 minutes from now
[root@solaris ~]# at now + 10 minutes
echo "Test mail" | mailx -s "Test" admin@example.com
<Ctrl+D>
job 3 at Mon Jan 20 10:25:00 2025

8. List and remove at jobs

Use atq to list jobs and atrm to remove them.

terminal — cron/at
solaris-lab
[root@solaris ~]# atq
2 Mon Jan 20 23:15:00 2025 a root
3 Mon Jan 20 10:25:00 2025 a root
 
# Remove job 3
[root@solaris ~]# atrm 3
 
[root@solaris ~]# atq
2 Mon Jan 20 23:15:00 2025 a root

Security: who is allowed to use cron and at?

  • Use /etc/cron.d/cron.allow and /etc/cron.d/cron.deny to control cron use.
  • Use /etc/cron.d/at.allow and /etc/cron.d/at.deny to control at use.
  • For security, allow only real application/service accounts to schedule jobs, not generic or guest users.
  • Review crontabs regularly for unknown or suspicious entries.

Important reminders

  • Always use absolute paths in cron and at (e.g. /usr/bin/find instead of find).
  • Set required environment (PATH, HOME, SHELL) in scripts, not just rely on login shell.
  • Log output to files using >> logfile 2>&1 so you can debug failures later.
  • For critical jobs, notify via mail or monitoring when they fail.