crontab

The idea behind making a crontab read-only is to :

forbid modification of the CRON jobs
while still letting them run normally

method 1 : change the spool file permissions

i.e., as :

chmod 400 /var/spool/cron/crontabs/kevin

This doesn't work because crontab has the setuid bit set, so that it is always executed as :

ll $(which crontab)

-rwxr-sr-x 1 root crontab 39K mars  31  2024 /usr/bin/crontab

method 2 : make the the spool file immutable

as :
chattr +i /var/spool/cron/crontabs/kevin

then, if I try to edit my crontab, as kevin :

myCrontabFile="$HOME/crontab.tmp"; crontab -l > "$myCrontabFile"; [edit "$myCrontabFile"]; crontab -n "$myCrontabFile" && crontab "$myCrontabFile" && rm "$myCrontabFile"

The syntax of the crontab file was successfully checked.	result of crontab -n "$myCrontabFile" : no error found 
crontab: crontabs/kevin: rename: Operation not permitted	result of crontab "$myCrontabFile" : can not overwrite immutable file

This method does the job albeit not being the cleanest one.

method 3 : using /etc/crony.deny (source) :

If testing this method right after trying the "immutable spool file" method, don't forget to make the spool file mutable again with : chattr -i /var/spool/cron/crontabs/kevin

as :
echo kevin >> /etc/cron.deny

then, if I try to edit my crontab, as kevin, with the same command :

You (kevin) are not allowed to use this program (crontab)
See crontab(1) for more information

As :

for username in $(cut -d : -f1 /etc/passwd); do echo "$username's CRONTAB :"; crontab -l -u $username; done | less
less /var/spool/cron/crontabs/*
/var/spool/cron/crontabs/* files are not intended to be edited directly. Use the crontab utility to edit CRON jobs.

~~/var/log/cron~~
~~/var/log/cronexecutionDate~~
grep CRON /var/log/syslog

With the exception of certain errors in the time fields, errors are not reported until CRON runs the command. All error messages and output are mailed to the crontab owner (or to any address specified with MAILTO=bob@example.com), unless they are silenced by redirecting stdout and stderr to /dev/null with >/dev/null 2>&1.
Even though completely silencing stdout and stderr by sending them to /dev/null looks tempting, this may not be a wise idea. If tasks generate too much jabber, you'd better fix your scripts or run tasks less frequently.
Output is mailed to the user because there is no terminal on which the cronjobs are being executed. Therefore, there is no screen to display the errors. Also, there is no keyboard to accept input. Does that mean you cannot give input to a CRON job? No. Think back to the discussion on shell scripts. We can redefine stdin, stdout and stderr. This way they can all point to files and behave as we expect.
Keep in mind that CRON is not exact :
- It synchronizes itself to the top of each minute.
- On a busy system in which you lose clock ticks, jobs may not be executed until a couple minutes after the scheduled time.
- In addition, there may be other processes with higher priorities that delay CRON jobs.
- In some cases, (particularly on very busy systems) jobs might end up being skipped if they are run every minute.

/etc/cron.d/*
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly
/etc/crontab
/etc/default/cron
/var/spool/cron/crontabs/kevin Debianoids only

Usage
Time specification
- fields
- wildcards
- aliases
Examples

Usage

crontab is used to :

submit jobs definition files to cron
list the contents of a cron table (personal or different user)

crontab option	Description
-e	edit the crontab with EDITOR
-l	list registered jobs (view the crontab)
-n	dry-run : check the syntax of the crontab file report errors (if any) leave
-r	remove the crontab
-u kevin	work on kevin's crontab when omitted, defaults to the user invoking crontab requires privileges
crontab myFile	register myFile as the new crontab, i.e. overwriting the previous crontab

crontab works so that you cannot append a new job at the end of a table. Instead, you have to :

extract the whole content of the table into a file :
- for the current user : crontab -l > /tmp/crontab
- as , for the user bob : crontab -l -u bob > /tmp/crontab.bob
You can also launch edition with vi (default) or your favorite editor at the same time with the -e option. If no crontab is available, just create a new text file and go to the next step.
edit the file to add / modify / delete jobs with your favorite text editor. The file MUST end with a blank line.
- you may define variables (aka environment settings) in the key = value form (spaces around the = sign are allowed) but there are limitations : these are not supported :
  - environmental substitutions : somePath = $HOME/bin
  - replacement of variables :
```
A=1
B=2
C=$A $B
```
  - tilde expansion : PATH = ~/bin
- about $PATH :
  - it is inherited from the environment (source : man -P 'less -p "PATH is inherited"' 5 crontab)
  - should you need to specify any non-standard value :
    - uncomment + edit the line in the crontab file header : #PATH=/usr/local/sbin:/usr/local/bin:
    - it is affected by the limitations above
check the syntax of the edited crontab file :
crontab -n /tmp/crontab
register the new crontab :
- for the current user : crontab /tmp/crontab
- as , for the user bob : crontab -u bob /tmp/crontab.bob

On Debianoids, failed CRON tasks are usually logged in (details) :
- /var/log/syslog
- /var/log/cron
- /var/log/messages
Looks like there's no concern about them appearing all uppercase in the log files : /USR/SBIN/CRON

crontab time specification (source : man 5 crontab) :

fields :

#	usage	range of values
1	minutes	0-59
2	hours	0-23
3	day of month	1-31
4	month	1-12 jan, feb, mar, apr,
5	day of week	0-6 (Sunday=0 or 7) sun, mon, tue, wed, thu, fri, sat

when specifying the day of month AND the day of week, both values are logically OR'd :
- the expression matches when any is true
- if both are true, the command is executed only once
in some web-based applications (such as Rundeck), you may encounter time specifications for scheduled tasks with up to 7 fields, like : 0 0 23 ? * * *
- even though they may be described as crontab jobs, these must be understood as scheduled jobs
- their format —which is NOT the official crontab format— extends it with :
  - 2 extra fields : seconds (as the 1^st field) and year (as the last one)
  - more wildcards
- this format was popularized by Quartz, which is the reference scheduler in the JVM business

wildcards :

character	usage	example (more examples below)
`*`	matches all values is actually an alias of first-last	`* * * * *` : run every minute of every hour of every day (very common but rarely a good idea IMHO)
`,`	list of values	`0 10,12,16 * * *` : run at 10:00, noon and 16:00
`-`	inclusive range of values	`30 11-13 * * ` : run at 11:30, 12:30 and 13:30 `0 0-4,7-9 * *` : run at 0:00, 1:00, 2:00, 3:00, 4:00 and 7:00, 8:00, 9:00 when using the `x-y` range syntax, x must be ≤ y
`/n`	do every n intervals	`/15 * * ` : run every 15 minutes `0 0–23/2 * ` is equivalent to `0 0,2,4,6,8,10,12,14,16,18,20,22 * *`
`~`	randomization `x~y` `~`	a random number is picked when the crontab file is parsed within the specified range, either : explicit : x-y implicit : the full range of values of the corresponding field (i.e. between 0 and 59 for minutes) same remark than for the range syntax : x must be ≤ y

aliases (source) :

Instead of the first five fields, one of eight special strings may appear :

string	meaning
`@reboot`	Run once, at startup.
`@yearly` `@annually`	Run once a year : `0 0 1 1 *`
`@monthly`	Run once a month : `0 0 1 * *`
`@weekly`	Run once a week : `0 0 * * 0`
`@daily` `@midnight`	Run once a day : `0 0 * * *`
`@hourly`	Run once an hour : `0 * * * *`

as for @reboot, the startup time is the time when the cron daemon itself started. Due to the boot order sequence of the machine, this _may_ be before some other system daemons (details)
(possibly obsolete) When are they executed ?

Using wildcards :

Let's say we wanted to run a command not at 10 minutes after the hour, but every ten minutes. We could make an entry that looked like this :

0,10,20,30,40,50	*	1,16	*	1-5	/usr/local/bin/command

This runs every 10 minutes: at the top of the hour, 10 minutes after, 20 minutes after, and so on. To make life easier, we could simply create the entry like this :

*/10	*	1,16	*	1-5	/usr/local/bin/command

The /n says that within the specific interval (in this case, every minute), run the command every n minutes; in this case, every 10 minutes.

We can also use this even when we specify a range. For example, if the job was only supposed to run between 20 minutes after the hour and 40 minutes after the hour, the entry might look like this :

20-40	*	1,16	*	1-5	/usr/local/bin/command

What if you wanted it to run at these times, but only every three minutes? The line might look like this :

20-40/3	*	1,16	*	1-5	/usr/local/bin/command

To make things even more complicated, you could say that you wanted the command to run every two minutes between the hour and 20 minutes after, every three minutes between 20 and 40 minutes after, then every 5 minutes between 40 minutes after and the hour :

0-20/2,21-40/3,41-59/5	*	1,16	*	1-5	/usr/local/bin/command

To make the fun last longer, let's imagine you have 2 jobs you want to execute every 2 minutes (source) : jobEven on even minutes : 2, 4, 6, ..., 58, 00 jobOdd on odd minutes : 1, 3, 5, ..., 59

*/2	*	*	*	*	jobEven
1-59/2	*	*	*	*	jobOdd

And what if I want a job to run every n minutes with `jobExecutionMinute % n != 0` ? (source)

Instead of :

1,6,11,16,21,26,31,36,41,46,51,56 * * * * /my/script
3,13,23,33,43,53 * * * * /my/other/script

you can do :

1-56/5 * * * * /my/script
3-53/10 * * * * /my/other/script

Remember :

Syntax : start-stop/increment
Ranges are inclusive : start and stop values are part of the range.

Monthly reboot :

# 1st monday of month at 6h30
30 6 * * 1 [ $(/bin/date +\%d) -lt 8 ] && /sbin/init 6

# Last wednesday of every month, at 6h30
#30 6 * * 3 [[ $(date +\%d) == $(echo "$(echo "$(cal -s )"|awk '{print $4}')"|tail -1) ]] && /sbin/init 6

# not tested yet

crontab - The utility to setup time-based jobs

How to make a crontab read-only ?

method 1 : change the spool file permissions

method 2 : make the the spool file immutable

method 3 : using /etc/crony.deny (source) :

How to view all users' crontabs ?

CRON job logs

crontab error management

Where are stored the crontabs ?

Table of contents

Usage

crontab time specification (source : man 5 crontab) :

fields :

wildcards :

aliases (source) :

Example

Using wildcards :

And what if I want a job to run every n minutes with `jobExecutionMinute % n != 0` ? (source)

Monthly reboot :

How to make a crontab read-only ?

method 1 : change the spool file permissions

method 2 : make the the spool file immutable

method 3 : using /etc/crony.deny (source) :

How to view all users' crontabs ?

CRON job logs

crontab error management

Where are stored the crontabs ?

crontab

Table of contents

Usage

crontab time specification (source : man 5 crontab) :

fields :

wildcards :

aliases (source) :

Example

Using wildcards :

And what if I want a job to run every n minutes with jobExecutionMinute % n != 0 ? (source)

Monthly reboot :

And what if I want a job to run every n minutes with `jobExecutionMinute % n != 0` ? (source)