Tag: crontab

How to Add Jobs to Cronjob in Unix (with Examples)

Learn how to schedule tasks using cron in Unix. This guide explains how to add, edit, and manage cron jobs with practical examples for beginners.

Cron jobs allows Unix users to run commands or scripts at a given date and time as per scheduled period of time. Cron is one of the most useful tool in a UNIX like operating systems. In Windows, same thing will be achieved by Scheduled Tasks. It is usually used for sysadmin jobs such as periodic backups, scripts to be executed on period of time or do any periodic activities and more. The cron service (daemon) runs in the background and constantly checks the/etc/crontab file, /etc/cron.*/ directories and /var/spool/cron/directory.

crontab command

crontab command is used to edit/create, install, deinstall or list the cron jobs in Cron. Every user can have their own crontab file, and though crontab files in /var/spool/cron/crontabs are not intended to be edited directly. Each user need to use crontab command for editing or setting up their own cron jobs.

Types of cron configuration files

There are different types of configuration files:

  1. The UNIX system crontab : Usually, used by system services and critical jobs that requires root like privileges. The sixth field (see below for field description) is the name of a user for the command to run as. This gives the system crontab the ability to run commands as any user.
  2. The user crontabs: User can install their own cron jobs using the crontab command. The sixth field is the command to run, and all commands run as the user who created the crontab

Note: This faq features cron implementations written by Paul Vixie and included in many Linux distributions and Unix like systems such as in the popular 4th BSD edition. The syntax is compatible with various implementations of crond service.

Install or create or edit cron jobs

To edit or create your own crontab file, type the following command at the UNIX / Linux shell prompt:

$ crontab -e

Cron will examine the modification time on all crontab files and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified.

Syntax of crontab (field description)

The syntax is:

1 2 3 4 5 /path/to/command arg1 arg2

OR

1 2 3 4 5 /root/backup.sh

Where,

  • 1: Minute (0-59)
  • 2: Hours (0-23)
  • 3: Day (0-31)
  • 4: Month (0-12 [12 == December])
  • 5: Day of the week(0-7 [7 or 0 == sunday])
  • /path/to/command – Script or command name to schedule

Easy to remember format:

* * * * * command to be executed
- - - - -
| | | | |
| | | | ----- Day of week (0 - 7) (Sunday=0 or 7)
| | | ------- Month (1 - 12)
| | --------- Day of month (1 - 31)
| ----------- Hour (0 - 23)
------------- Minute (0 - 59)

Your cron job looks as follows for system jobs:

1 2 3 4 5 USERNAME /path/to/command arg1 arg2

OR

1 2 3 4 5 USERNAME /path/to/script.sh

Example: Run backup cron job script

If you wished to have a script named /root/backup.sh run every day at 3am, your crontab entry would look like as follows. First, install your cronjob by running the following command:

# crontab -e

Append the following entry:

0 3 * * * /root/backup.sh

Save and close the file.

More examples

To run /path/to/command five minutes after midnight, every day, enter:

5 0 * * * /path/to/command

Run /path/to/script.sh at 2:15pm on the first of every month, enter:

15 14 1 * * /path/to/script.sh

Run /scripts/phpscript.php at 10 pm on weekdays, enter:

0 22 * * 1-5 /scripts/phpscript.php

Run /root/scripts/perl/perlscript.pl at 23 minutes after midnight, 2am, 4am …, everyday, enter:

23 0-23/2 * * * /root/scripts/perl/perlscript.pl

Run /path/to/unixcommand at 5 after 4 every Sunday, enter:

5 4 * * sun /path/to/unixcommand

How do I use operators?

An operator allows can be used to specifying multiple values in a field. There are three operators:

  1. The asterisk (*) : This operator specifies all possible values for a field. For example, an asterisk in the hour time field would be equivalent to every hour or an asterisk in the month field would be equivalent to every month.
  2. The comma (,) : This operator specifies a list of values, for example: “1,5,10,15,20, 25”.
  3. The dash (-) : This operator specifies a range of values, for example: “5-15” days , which is equivalent to typing “5,6,7,8,9,….,13,14,15” using the comma operator.
  4. The separator (/) : This operator specifies a step value, for example: “0-23/” can be used in the hours field to specify command execution every other hour. Steps are also permitted after an asterisk, so if you want to say every two hours, just use */2.

How do I disable email output?

By default the output of a command or a script (if any produced), will be email to provided email account. To stop receiving email output from crontab, append >/dev/null 2>&1. For example:

0 3 * * * /root/backup.sh >/dev/null 2>&1

To mail output to particular email account let us say abc@example.com, define MAILTO variable as follows:

MAILTO="vivek@nixcraft.in"
0 3 * * * /root/backup.sh >/dev/null 2>&1

Task: List all your cron jobs

Type the following command:

// List all cron jobs
# crontab -l

// List cron jobs of specific user. Must be run as the root user
# crontab -u username -l

To remove or erase all crontab jobs use the following command:

// Delete all current cron jobs
crontab -r

// Delete cron jobs of specific user. Must be run as the root user
crontab -r -u username

Use special string to save time

Instead of the first five fields, use any one of eight special strings. It will not just save time but also improve readability.

Special stringMeaning
@rebootRun once, at startup.
@yearlyRun once a year, “0 0 1 1 *”.
@annually(same as @yearly)
@monthlyRun once a month, “0 0 1 * *”.
@weeklyRun once a week, “0 0 * * 0”.
@dailyRun once a day, “0 0 * * *”.
@midnight(same as @daily)
@hourlyRun once an hour, “0 * * * *”.

Examples

Run ntpdate command every hour:

@hourly /path/to/ntpdate

Make a backup everyday:

@daily /path/to/backup/script.sh

More about /etc/crontab file and /etc/cron.d/* directories

/etc/crontab is system crontabs file. Usually only used by root user or daemons to configure system wide jobs. All individual user must use crontab command to install and edit their jobs as described above. /var/spool/cron/ or /var/cron/tabs/ is directory for personal user crontab files. It must be backup with users home directory.

Understanding Default /etc/crontab

Typical /etc/crontab file entries:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

First, the environment must be defined. If the shell line is omitted, cron will use the default, which is sh.

If the PATH variable is omitted, no default will be used and file locations will need to be absolute.

If HOME is omitted, cron will use the invoking users home directory.

Additionally, cron reads the files in /etc/cron.d/ directory. Usually system daemon such as sa-update or sysstat places their cronjob here and used as the root user or superuser to configure cron jobs. Users can directly drop your scripts here. The run-parts command run scripts or programs in a directory via /etc/crontab file:

DirectoryDescription
/etc/cron.d/Put all scripts here and call them from /etc/crontab file.
/etc/cron.daily/Run all scripts once a day
/etc/cron.hourly/Run all scripts once an hour
/etc/cron.monthly/Run all scripts once a month
/etc/cron.weekly/Run all scripts once a week

Examples

Here is a sample shell script called clean.cache. This script is created to clean up cached files every 10 days. This script is directly created at /etc/cron.daliy/ directory. In other words create a text file called /etc/cron.daily/clean.cache as follows.

 #!/bin/bash
# A sample shell script to clean cached file from lighttpd web server
CROOT="/tmp/cachelighttpd/"
 
# Clean files every $DAYS
DAYS=10
 
# Web server username and group name
LUSER="lighttpd"
LGROUP="lighttpd"
 
# Okay, let us start cleaning as per $DAYS
/usr/bin/find ${CROOT} -type f -mtime +${DAYS} | xargs -r /bin/rm
 
# Failsafe 
# if directory deleted by some other script just get it back 
if [ ! -d $CROOT ]
then
        /bin/mkdir -p $CROOT
        /bin/chown ${LUSER}:${LGROUP} ${CROOT}
fi

Save and close the file. Set the permissions:

# chmod +x /etc/cron.daily/clean.cache

Backup installed cron job entries

Simply type the following command to backup cronjobs to a nas server mounted at /nas01/backup/cron/users.root.bakup directory:

// Backup all cron jobs
# crontab -l > /nas01/backup/cron/users.root.bakup

// Backup cron jobs of specific user
# crontab -u userName -l > /nas01/backup/cron/users.userName.bakup

See also

See man pages for more information cron(8), crontab(1), crontab(5), run-parts(8)

Automatically Kill Slow MySQL Queries After N Seconds

Learn how to detect and automatically terminate slow MySQL queries after a set duration. Improve performance and avoid database slowdowns.

Maintaining a performant MySQL-backed application requires smart tuning. Without it, connections may pile up, queries stall, and user experience suffers dramatically, especially due to slow queries.

If you’re using persistent connections, idle or long-running queries can accumulate in SLEEP mode for a log time. One quick solution – especially on MySQL ≥ 5.1 – is to periodically scan the process list and terminate any query that’s been running longer than your acceptable threshold and currently in SLEEP mode.

In this post, we will learn some techniques to identify these slow queries and kill them to improve the performance of the application.

Step 1: Generate KILL QUERY Statements

This SQL query will produce the necessary KILL QUERY commands for any non-system query exceeding your time limit (e.g., 1200 seconds = 20 minutes):

SELECT
  GROUP_CONCAT(
    CONCAT('KILL QUERY ', id, ';')
    SEPARATOR ' '
  ) AS kill_cmds
FROM information_schema.processlist
WHERE user <> 'system user'
  AND time >= 1200;

You can customize the filter via the info column – for instance, if you want queries from specific database (db) or certain query patterns, you can apply those filters to info column and update the above query accordingly.

This query gives you the complete list of slow queries as per your filters. But, you need to run it everytime, whenever you want this data.

So, to automate this process, add this query to cronjob via a shell script.

Step 2: Automate with a Shell Script

Wrap this logic in a shell script and schedule it with cron to run at regular intervals. Here’s a refined example:

SECONDS_TOO_LONG=1200

QUERIES_RUNNING_TOO_LONG=`mysql -uroot -ppassword -ANe"SELECT COUNT(1) FROM information_schema.processlist WHERE user <> 'system user' AND time >= ${SECONDS_TOO_LONG}"`

if [ ${QUERIES_RUNNING_TOO_LONG} -gt 0 ]
then
    KILLPROC_SQLSTMT="SELECT GROUP_CONCAT(CONCAT('KILL QUERY ',id,';') SEPARATOR ' ') KillQuery FROM information_schema.processlist WHERE user <> 'system user' AND time >= ${SECONDS_TOO_LONG}"
    mysql -uroot -ppassword -ANe"${KILLPROC_SQLSTMT}" | mysql -uroot -ppassword
fi

This ends all slow MySQL queries running over 20 minutes and can be scheduled every few minutes in crontab.

Alternative: Log and Kill via a Temporary SQL File

Alternatively, if you want to log all the slow MySQL queries before killing them, here’s a safe method:

SECONDS_TOO_LONG=1200

QUERIES_RUNNING_TOO_LONG=`mysql -uroot -ppassword -ANe"SELECT COUNT(1) FROM information_schema.processlist WHERE user <> 'system user' AND time >= ${SECONDS_TOO_LONG}"`
if [ ${QUERIES_RUNNING_TOO_LONG} -gt 0 ]
then
    KILLPROC_SQLSTMT="SELECT CONCAT('KILL QUERY ',id,';') KillQuery FROM information_schema.processlist WHERE user <> 'system user' AND time >= ${SECONDS_TOO_LONG}"
    mysql -uroot -ppassword -ANe"${KILLPROC_SQLSTMT}" > /tmp/kill_log_queries.sql
    mysql -uroot -ppassword < /tmp/kill_log_queries.sql
fi

This approach gives you a chance to log or inspect the kill commands before they run.

Want to learn more about tuning MySQL performance? Get High Performance MySQL book from https://amzn.to/4dVaueF

Built-In Per-Session Execution Timeout (MySQL 5.7+)

If you’re using MySQL 5.7.4+, a cleaner solution exists:

SET GLOBAL max_execution_time = 5000; -- Timeout in milliseconds

This applies a soft execution limit to all SELECT queries (read-only) at runtime. Once exceeded, MySQL aborts the query with an error but keeps the session alive.

You can also set per-session limits:

SET SESSION max_execution_time = 2000;

Or use the hint syntax on specific queries:

SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM your_table;

Conclusion

Choose the approach that fits your environment:

  • Older MySQL (< 5.7): Use a cron-driven shell script targeting INFORMATION_SCHEMA.PROCESSLIST.
  • MySQL 5.7.4 and above: Prefer max_execution_time or per-query hints for cleaner, built-in enforcement.

They all help safeguard against runaway queries that could otherwise lock up your server.

Disclaimer: This post contains affiliate links. If you use these links to buy something, I may earn a commission at no extra cost to you.