Cron руководство по

Cron — один из часто используемых инструментов для Unix-систем. Его используют для планирования выполнения команд на определённое время. Эти «отложенные» команды или задания принято называть «Cron Jobs». Такой инструмент отлично подходит для регулярных бэкапов, мониторинга дискового пространства, удаления файлов (например, логов) и много чего ещё. В этой статье будет рассказано о работе с Cron на Linux.

Введение

Шаблон задания для Cron выглядит примерно так:

Минуты(0-59) Часы(0-24) День(1-31) Месяц(1-12) День недели(0-6) Команда

Вот иллюстрация этого же шаблона, которую можно сохранить себе:

Звёздочками обозначены конкретные блоки времени.

Для отображения содержимого crontab-файла текущего пользователя используйте команду:

$ crontab -l

Для редактирования заданий пользователя есть команда:

$ crontab -e

Если эта команда выполняется в первый раз, вам предложат выбрать редактор для Cron:

no crontab for sk - using an empty one

Select an editor. To change later, run 'select-editor'.
 1. /bin/nano <---- простейший
 2. /usr/bin/vim.basic
 3. /usr/bin/vim.tiny
 4. /bin/ed

Choose 1-4 [1]:

Выбирайте на своё усмотрение. Вот так изначально выглядит crontab-файл:

В этом файле как раз нужно перечислять одну за другой все команды.

Чтобы изменить crontab-файл другого пользователя (например, ostechnix):

$ crontab -u ostechnix -e

Ниже приведены несколько примеров cron-заданий:

1. Чтобы выполнять команду каждую минуту, задание должно быть такое:

   * * * * * <исполняемая-команда>

2. Похожее задание, только команда будет вызываться каждые пять минут:

   */5 * * * * <исполняемая-команда>

3. Вызывать команду 4 раза в час (каждые 15 минут):

   */15 * * * * <исполняемая-команда>

4. Чтобы выполнить команду каждый час в 30 минут, пишем:

   30 * * * * <исполняемая-команда>

   Т. е. команда будет выполняться не каждые 30 минут, а тогда, когда значение минут будет равно 30 (например, 10:30, 11:30, 12:30 и т. д.).

5. Значения времени можно комбинировать, перечислив их через запятую. Следующий код будет выполнять команду три раза в час: в 0, 5 и 10 минут.

   0,5,10 * * * * <исполняемая-команда>

6. Выполнять команду каждый час будет следующее задание:

   0 * * * * <исполняемая-команда>

7. Выполнение команды каждые два часа:

   0 */2 * * * <исполняемая-команда>

8. Чтобы выполнять команду каждый день (в 00:00):

   0 0 * * * <исполняемая-команда>

9. Выполнение команды каждый день в 03:00:

   0 3 * * * <исполняемая-команда>

10. Выполнение команды каждое воскресенье (sunday):

    0 0 * * SUN <исполняемая-команда>

11. Другой вариант задания, которое будет выполнять команду каждое воскресенье (естественно, тоже в 00:00):

    0 0 * * 0 <исполняемая-команда>

12. Выполнение команды каждый день с понедельника по пятницу:

    0 0 * * 1-5 <исполняемая-команда>

13. Следующее задание будет выполнять команду каждый месяц, 1-го числа в 00:00:

    0 0 1 * * <исполняемая-команда>

14. Выполнять команду в 16:15 каждого первого числа месяца будет это задание:

    15 16 1 * * <исполняемая-команда>

15. Выполнение команды каждые три месяца:

    0 0 1 */3 * <исполняемая-команда>

16. Выполнение команды в строго определённое время и месяц:

    5 0 * 4 * <исполняемая-команда>

17. Задание будет вызывать команду в начале каждого полугодия (в 00:00 1-го дня):

    0 0 1 */6 * <исполняемая-команда>

18. Выполнение команды каждый год 1-го января в 00:00:

    0 0 1 1 * <исполняемая-команда>

Ещё существуют готовые задания:

• @reboot — одиночное выполнение команды при загрузке;
• @yearly — раз в год;
• @annually — тоже раз в год;
• @monthly — раз в месяц;
• @weekly — один раз в неделю;
• @daily —  раз в день;
• @midnight — тоже раз в день;
• @hourly — раз в час.

Чтобы выполнять команду каждый раз после перезапуска сервера, используйте это задание:

@reboot <исполняемая-команда>

Команда для очистки всех заданий текущего пользователя:

$ crontab -r

Чтобы узнать о подробностях, есть команда:

$ man crontab

Вышеперечисленного уже должно хватить для базовой работы с Cron и составления заданий.

Синтаксис crontab-генераторов

Процесс написания заданий сильно упрощают веб-инструменты. Они не требуют знаний синтаксиса Cron, потому что у них графический интерфейс, а задания генерируются в соответствии с вводимыми данными. Сайт генерирует задание, которое можно будет просто скопировать и вставить в crontab-файл.

Crontab.guru

crontab.guru — отличный сайт, чтобы изучить различные примеры cron-заданий. Просто введите данные и сайт самостоятельно сгенерирует конечное задание.

На сайте есть разделы, посвящённые примерам и советам.

Crontag Generator

crontab-generator.org — ещё один сайт, который помогает быстро сгенерировать crotab-выражения. Принцип такой же: нужно ввести все необходимые данные в формы и нажать кнопку «Generate Crontab Line» внизу страницы.

Вот такое конечное выражение вы увидете на сайте:

Помимо этого, есть веб-инструмент «Crontab UI», который обеспечивает не только простоту создания crontab-заданий, но и безопасность. Вот статья, посвящённая этому инструменту.

Перевод статьи «A Beginners Guide To Cron Jobs»

From Wikipedia:

cron is the time-based job scheduler in Unix-like computer operating systems. cron enables users to schedule jobs (commands or shell scripts) to run periodically at certain times, dates or intervals. It is commonly used to automate system maintenance or administration.

Installation

There are many cron implementations, but none of them are installed by default as the base system uses systemd/Timers instead. See the Gentoo’s cron guide, which offers comparisons.

Packages available:

• cronie
• fcron
• dcron^AUR
• vixie-cron^AUR
• fcron-dev^AUR
• scron-git^AUR

Configuration

Activation and autostart

After installation, the daemon will not be enabled by default. The installed package likely provides a service, which can be controlled by systemctl. For example, cronie uses cronie.service.

Check /etc/cron.daily/ and similar directories to see which jobs are present. Activating cron service will trigger all of them.

Note: cronie provides the 0anacron hourly job, which allows for delayed runs of other jobs e.g. if the computer was switched off at the moment of standard execution.

Handling errors of jobs

cron registers the output from stdout and stderr and attempts to send it as email to the user’s spools via the sendmail command. Cronie disables mail output if /usr/bin/sendmail is not found. In order for mail to be written to a user’s spool, there must be an smtp daemon running on the system, e.g. opensmtpd. Otherwise, you can install a package that provides the sendmail command, and configure it to send mail to a remote mail exchanger. You can also log the messages by using the -m option and writing a custom script.

Tip: One can send the output to local system users using Postfix#Local mail.

1. Edit the cronie.service unit.
2. Install esmtp^AUR, msmtp, opensmtpd, sSMTP, or write a custom script.

Example with sSMTP

sSMTP is a send-only sendmail emulator which delivers email from a local computer to an smtp server. While there are currently no active maintainers, it is still by far the simplest way to transfer mail to a configured mailhub. There are no daemons to run, and configuration can be as simple as editing 3 lines in a single configuration file (if your host is trusted to relay unauthenticated email through your mailhub). sSMTP does not receive mail, expand aliases, or manage a queue.

Install ssmtp^AUR, which creates a symbolic link from /usr/bin/sendmail to /usr/bin/ssmtp. You must then edit /etc/ssmtp/ssmtp.conf. See sSMTP for details. Creating a symbolic link to /usr/bin/sendmail insures that programs like S-nail (or any package which provides /usr/bin/mail) will just work without modification.

Restart cronie.service to insure that it detects that you now have a /usr/bin/sendmail installed.

Example with msmtp

Install msmtp-mta, which creates a symbolic link from /usr/bin/sendmail to /usr/bin/msmtp. Restart cronie.service to make sure it detects the new sendmail command. You must then provide a way for msmtp to convert your username into an email address.

Then either add MAILTO line to your crontab, like so:

MAILTO=your@email.com

or create /etc/msmtprc and append this line:

aliases /etc/aliases

and create /etc/aliases:

your_username: your@email.com
# Optional:
default: your@email.com

Then modify the configuration of cronie daemon by replacing the ExecStart command with:

ExecStart=/usr/bin/crond -n -m '/usr/bin/msmtp -t'

Example with esmtp

Install esmtp^AUR and procmail^AUR.

After installation configure the routing:

/etc/esmtprc

identity myself@myisp.com
       hostname mail.myisp.com:25
       username "myself"
       password "secret"
       starttls enabled
       default
mda "/usr/bin/procmail -d %T"

Procmail needs root privileges to work in delivery mode but it is not an issue if you are running the cronjobs as root anyway.

To test that everything works correctly, create a file message.txt with "test message" in it.

From the same directory run:

$ sendmail user_name < message.txt 

then:

$ cat /var/spool/mail/user_name

You should now see the test message and the time and date it was sent.

The error output of all jobs will now be redirected to /var/spool/mail/user_name.

Due to the privileged issue, it is hard to create and send emails to root (e.g. su -c ""). You can ask esmtp to forward all root’s email to an ordinary user with:

/etc/esmtprc

force_mda="user-name"

$ chmod 710 ~/.esmtprc

Example with opensmtpd

Install opensmtpd.

Edit /etc/smtpd/smtpd.conf. The following configuration allows for local delivery:

listen on localhost
action "local" mbox alias <aliases>
match for local action "local"

You can proceed to test it. First start smtpd.service. Then do:

$ echo test | sendmail user

user can check their mail in with any reader able to handle mbox format, or just have a look at the file /var/spool/mail/user. If everything goes as expected, you can enable opensmtpd for future boots.

This approach has the advantage of not sending local cron notifications to a remote server. On the downside, you need a new daemon running.

Long cron job

Suppose this program is invoked by cron :

#!/bin/sh
echo "I had a recoverable error!"
sleep 1h

What happens is this:

1. cron runs the script
2. as soon as cron sees some output, it runs your MTA, and provides it with the headers. It leaves the pipe open, because the job has not finished and there might be more output.
3. the MTA opens the connection to postfix and leaves that connection open while it waits for the rest of the body.
4. postfix closes the idle connection after less than an hour and you get an error like this :

   smtpmsg='421 … Error: timeout exceeded' errormsg='the server did not accept the mail'

To solve this problem you can use the command chronic or sponge from moreutils.
From their respective man page:

chronic(1)

chronic runs a command, and arranges for its standard out and standard error to only be displayed if the command fails (exits nonzero or crashes). If the command succeeds, any extraneous output will be hidden.

sponge(1)

sponge reads standard input and writes it out to the specified file. Unlike a shell redirect, sponge soaks up all its input before opening the output file… If no output file is specified, sponge outputs to stdout.

Chronic too buffers the command output before opening its standard output.

Crontab format

The basic format for a crontab is:

minute hour day_of_month month day_of_week command

• minute values can be from 0 to 59.
• hour values can be from 0 to 23.
• day_of_month values can be from 1 to 31.
• month values can be from 1 to 12.
• day_of_week values can be from 0 to 6, with 0 denoting Sunday.

Spaces are used to separate fields. To fine-tune your schedule you may also use one of the following symbols:

For example, the line:

*/5 9-16 * 1-5,9-12 1-5 ~/bin/i_love_cron.sh

will execute the script i_love_cron.sh at five minute intervals from 9 AM to 4:55 PM on weekdays except during the months of June, July, and August.

In addition, crontab has some special keywords:

For example:

@reboot ~/bin/i_love_cron.sh

will execute the script i_love_cron.sh at startup.

See more at: https://www.adminschoice.com/crontab-quick-reference

More examples and advanced configuration techniques can be found below.

Basic commands

Crontabs should never be edited directly; instead, you should use the crontab program to work with your crontabs.

To view your crontabs:

$ crontab -l

To edit your crontabs:

$ crontab -e

To remove all of your crontabs:

$ crontab -r

If you have a saved crontab and would like to completely overwrite your old crontab:

$ crontab saved_crontab_filename

To overwrite a crontab from the command line (Wikipedia:stdin):

$ crontab - 

To edit somebody else’s crontab:

# crontab -u username -e

This same format (appending -u username to a command) works for listing and deleting crontabs as well.

Examples

The entry:

01 * * * * /bin/echo Hello, world!

runs the command /bin/echo Hello, world! on the first minute of every hour of every day of every month (i.e. at 12:01, 1:01, 2:01, etc.).

Similarly:

*/5 * * jan mon-fri /bin/echo Hello, world!

runs the same job every five minutes on weekdays during the month of January (i.e. at 12:00, 12:05, 12:10, etc.).

The line (as noted in crontab(5)):

*0,*5 9-16 * 1-5,9-12 1-5 /home/user/bin/i_love_cron.sh

will execute the script i_love_cron.sh at five minute intervals from 9 AM to 5 PM (excluding 5 PM itself) every weekday (Mon-Fri) of every month except during the summer (June, July, and August).

Periodical settings can also be entered as in this crontab template:

# Chronological table of program loadings                                       
# Edit with "crontab" for proper functionality, "man 5 crontab" for formatting
# User: johndoe

# mm  hh  DD  MM  W /path/progam [--option]...  ( W = weekday: 0-6 [Sun=0] )
  21  01  *   *   * /usr/bin/systemctl hibernate
  @weekly           $HOME/.local/bin/trash-empty

Here are some self-explanatory crontab syntax examples:

30 4 echo "It is now 4:30 am."
0 22 echo "It is now 10 pm."
30 15 25 12 echo "It is 3:30pm on Christmas Day."
30 3 * * * echo "Remind me that it's 3:30am every day."
0 * * * * echo "It is the start of a new hour."
0 6 1,15 * * echo "At 6am on the 1st and 15th of every month."
0 6 * * 2,3,5 echo "At 6am on Tuesday, Wednesday and Thursdays."
59 23 * * 1-5 echo "Just before midnight on weekdays."
0 */2 * * * echo "Every two hours."
0 20 * * 4 echo "8pm on a Thursday."
0 20 * * Thu echo "8pm on a Thursday."
*/15 9-17 * * 2-5 echo "Every 15 minutes from 9am-5pm on weekdays."
@yearly echo "Happy New Year!"

Default editor

To use an alternate default editor, define the EDITOR environment variable in a shell initialization script as described in Environment variables.

As a regular user, su will need to be used instead of sudo for the environment variable to be pulled correctly:

$ su -c "crontab -e"

To have an alias to this printf is required to carry the arbitrary string because su launches in a new shell:

alias scron="su -c $(printf "%q " "crontab -e")"

Running X.org server-based applications

Cron does not run under the X.org server therefore it cannot know the environmental variable necessary to be able to start an X.org server application so they will have to be defined. One can use a program like xuserrun-git^AUR to do it:

17 02 * ... /usr/bin/xuserrun /usr/bin/xclock

Or they can be defined manually (echo $DISPLAY will give the current DISPLAY value):

17 02 * ... env DISPLAY=:0 /usr/bin/xclock

If running notify-send for desktop notifications in cron, notify-send is sending values to dbus. So it needs to tell dbus to connect to the right bus.
The address can be found by examining DBUS_SESSION_BUS_ADDRESS environment variable and setting it to the same value. Therefore:

17 02 * ... env DBUS_SESSION_BUS_ADDRESS=your-address notify-send 'Foo bar'

If done through say SSH, permission will need be given:

# xhost +si:localuser:$(whoami)

Asynchronous job processing

If you regularly turn off your computer but do not want to miss jobs, there are some solutions available (easiest to hardest):

Cronie

cronie comes with anacron included. The project homepage says:

Cronie contains the standard UNIX daemon crond that runs specified programs at scheduled times and related tools.
It is based on the original cron and has security and configuration enhancements like the ability to use pam and SELinux.

Dcron

Vanilla dcron^AUR supports asynchronous job processing. Just put it with @hourly, @daily, @weekly or @monthly with a jobname, like this:

@hourly         ID=greatest_ever_job      echo This job is very useful.

Cronwhip

cronwhip^AUR is a script to automatically run missed cron jobs; it works with the former default cron implementation, dcron.
See also the forum thread.

Anacron

Anacron is a full replacement for dcron which processes jobs asynchronously.

It is provided by cronie. The configuration file is /etc/anacrontab. Information on the format can be found in the anacrontab(5). Running anacron -T will test /etc/anacrontab for validity.

Fcron

Like anacron, fcron assumes the computer is not always running and, unlike anacron, it can schedule events at intervals shorter than a single day which may be useful for systems which suspend/hibernate regularly (such as a laptop). Like cronwhip, fcron can run jobs that should have been run during the computer’s downtime.

When replacing cronie with fcron be aware the spool directory is /var/spool/fcron and the fcrontab command is used instead of crontab to edit the user crontabs. These crontabs are stored in a binary format with the text version next to them as foo.orig in the spool directory. Any scripts which manually edit user crontabs may need to be adjusted due to this difference in behavior.

A quick scriptlet which may aide in converting traditional user crontabs to fcron format:

cd /var/spool/cron && (
 for ctab in *; do
  fcrontab ${ctab} -u ${ctab}
 done
)

See also the forum thread.

Ensuring exclusivity

If you run potentially long-running jobs (e.g., a backup might all of a sudden run for a long time, because of many changes or a particular slow network connection), then flock (util-linux) can ensure that the cron job will not start a second time.

  5,35 * * * * /usr/bin/flock -n /tmp/lock.backup /root/make-backup.sh

Cronie

The relevant file hierarchy for cronie is the following:

   /etc/
     |----- cron.d/
              | ----- 0hourly
     |----- cron.minutely/
     |----- cron.hourly/
              | ----- 0anacron
     |----- anacrontab
     |----- cron.daily/
     |----- cron.monthly/
     |----- cron.weekly/
     |----- crontab
     |----- cron.deny

Cronie provides both cron and anacron functionalities: cron runs jobs at regular time intervals (down to a granularity of one minute) as long as the system is available at the specified time, while anacron executes commands at
intervals specified in days. Unlike cron, it does not assume that the system is running continuously. Whenever the system is up, anacron checks if there are any jobs that should have been run and handles them accordingly.

A cron job can be defined in a crontab-like file in the /etc/cron.d directory or added within the /etc/crontab file. Note the latter is not present by default but is used if it exists. As instructed by /etc/cron.d/0hourly, any executable file in /etc/cron.hourly will be run every hour (by default at minute 1 of the hour). Files in /etc/cron.minutely are executed every minute if instructed accordingly in /etc/cron.d/0hourly. The executables are typically shell scripts, symlinks to executable files can also be used.
The /etc/cron.deny file includes the list of users not allowed to use crontab, without this file, only users listed in /etc/cron.allow can use it.

Anacron works similarly, by executing the files in the /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly directories, placed there depending on the desired job frequency. The cron job /etc/cron.hourly/0anacron makes sure that anacron is run once daily to perform its pending tasks.

0 1 5 10 * /path/to/script.sh >/dev/null 2>&1

Dcron

The cron daemon parses a configuration file known as crontab. Each user on the system can maintain a separate crontab file to schedule commands individually. The root user’s crontab is used to schedule system-wide tasks (though users may opt to use /etc/crontab or the /etc/cron.d directory, depending on which cron implementation they choose).

/var/spool/cron/root

# Run command at a scheduled time
# Edit this 'crontab -e' for error checking, man 1 crontab for acceptable format

# <@freq>                       <tags and command>
@hourly         ID=sys-hourly   /usr/sbin/run-cron /etc/cron.hourly
@daily          ID=sys-daily    /usr/sbin/run-cron /etc/cron.daily
@weekly         ID=sys-weekly   /usr/sbin/run-cron /etc/cron.weekly
@monthly        ID=sys-monthly  /usr/sbin/run-cron /etc/cron.monthly

# mm  hh  DD  MM  W /path/command (or tags) # W = week: 0-6, Sun=0
  21  01  *   *   * /usr/bin/systemctl suspend

These lines exemplify one of the formats that crontab entries can have, namely whitespace-separated fields specifying:

1. @period
2. ID=jobname (this tag is specific to dcron)
3. command

The other standard format for crontab entries is:

1. minute
2. hour
3. day
4. month
5. day of week
6. command

The crontab files themselves are usually stored as /var/spool/cron/username. For example, root’s crontab is found at /var/spool/cron/root

See the crontab man page for further information and configuration examples.

See also

• Gentoo Linux Cron Guide
• crontab.guru — online editor for cronjob expressions

Introduction

Cron is a system daemon used to execute desired tasks (in the background) at designated times.

A crontab file is a simple text file containing a list of commands meant to be run at specified times. It is edited using the crontab command. The commands in the crontab file (and their run times) are checked by the cron daemon, which executes them in the system background.

Each user (including root) has a crontab file. The cron daemon checks a user’s crontab file regardless of whether the user is actually logged into the system or not.

To display the on-line help for crontab enter:

 man crontab

or further information is available from the OpenGroup specifications.

On Gnome-based Ubuntu systems Gnome Scheduled tasks tool (from the gnome-schedule package) in Applications —> System Tools provides a graphical interface with prompting for using Cron. The project website is at http://gnome-schedule.sourceforge.net/; the software is installable from the Software Center or by typing

sudo apt-get install gnome-schedule

in a terminal.

Starting to Use Cron

To use cron for tasks meant to run only for your user profile, add entries to your own user’s crontab file. To edit the crontab file enter:

crontab -e

Edit the crontab using the format described in the next sections. Save your changes. (Exiting without saving will leave your crontab unchanged.) To display the on-line help describing the format of the crontab file enter:

man 5 crontab

Commands that normally run with administrative privileges (i.e. they are generally run using sudo) should be added to the root crontab. To edit the root crontab enter:

 sudo crontab -e

Crontab Lines

Each line has five time-and-date fields, followed by a command, followed by a newline character (‘n’). The fields are separated by spaces. The five time-and-date fields cannot contain spaces. The five time-and-date fields are as follows: minute (0-59), hour (0-23, 0 = midnight), day (1-31), month (1-12), weekday (0-6, 0 = Sunday).

01 04 1 1 1 /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on January 1st plus every Monday in January.

An asterisk (*) can be used so that every instance (every hour, every weekday, every month, etc.) of a time period is used.

01 04 * * * /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on every day of every month.

Comma-separated values can be used to run more than one instance of a particular command within a time period. Dash-separated values can be used to run a command continuously.

01,31 04,05 1-15 1,6 * /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 01 and 31 past the hours of 4:00am and 5:00am on the 1st through the 15th of every January and June.

The «/usr/bin/somedirectory/somecommand» text in the above examples indicates the task which will be run at the specified times. It is recommended that you use the full path to the desired commands as shown in the above examples. Enter which somecommand in the terminal to find the full path to somecommand. The crontab will begin running as soon as it is properly edited and saved.

You may want to run a script some number of times per time unit. For example if you want to run it every 10 minutes use the following crontab entry (runs on minutes divisible by 10: 0, 10, 20, 30, etc.)

*/10 * * * * /usr/bin/somedirectory/somecommand

which is also equivalent to the more cumbersome

0,10,20,30,40,50 * * * * /usr/bin/somedirectory/somecommand

Cron also offers some special strings, which can be used in place of the five time-and-date fields:

• string	meaning
  @reboot	Run once, at startup.
  @yearly	Run once a year, «0 0 1 1 *».
  @annually	(same as @yearly)
  @monthly	Run once a month, «0 0 1 * *».
  @weekly	Run once a week, «0 0 * * 0».
  @daily	Run once a day, «0 0 * * *».
  @midnight	(same as @daily)
  @hourly	Run once an hour, «0 * * * *».

@reboot /path/to/execuable1

The above example will execute /path/to/executable1 when the system starts.

For more information on special strings enter «man 5 crontab».

Crontab Options

• The -l option causes the current crontab to be displayed on standard output.
• The -r option causes the current crontab to be removed.
• The -e option is used to edit the current crontab using the editor specified by the EDITOR environment variable.

After you exit from the editor, the modified crontab is checked for errors and, if there are no errors, it is installed automatically. The file is stored in /var/spool/cron/crontabs but should only be edited using the crontab command.

Allowing/Denying User-Level Cron

If the /etc/cron.allow file exists, then users must be listed in it in order to be allowed to run the crontab command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does, then users must not be listed in the /etc/cron.deny file in order to run crontab.

In the case where neither file exists, the default on current Ubuntu (and Debian, but not some other Linux and UNIX systems) is to allow all users to run jobs with crontab.

No cron.allow or cron.deny files exist in a standard Ubuntu install, so all users should have cron available by default, until one of those files is created. If a blank cron.deny file has been created, that will change to the standard behavior users of other operating systems might expect: cron only available to root or users in cron.allow.

Note, userids on your system which do not appear in /etc/shadow will NOT have operational crontabs, if you desire to enter a user in /etc/passwd, but NOT /etc/shadow that user’s crontab will never run. Place an entry in /etc/shadow for the user with a * for the password crypt, eg:

joeuser:*:15169::::::

Further Considerations

Crontab commands are generally stored in the crontab file belonging to your user account (and executed with your user’s level of permissions). If you want to regularly run a command requiring administrative permissions, edit the root crontab file:

sudo crontab -e

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of the root crontab file:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

crontab -e uses the EDITOR environment variable. To change the editor to your own choice, just set that variable. You may want to set EDITOR in your .bashrc because many commands use this variable. For example, in order to set the editor to be nano (a very easy editor to use) add this line to .bashrc:

export EDITOR=nano

It is sensible to test that your cron jobs work as intended. One method for doing this is to set up the job to run a couple of minutes in the future and then check the results before finalising the timing. You may also find it useful to put the commands into script files that log their success or failure, for example:

echo "Nightly Backup Successful: $(date)" >> /tmp/mybackup.log

If your machine is regularly switched off, you may also be interested in at and anacron, which provide other approaches to scheduled tasks. For example, anacron offers simple system-wide directories for running commands hourly, daily, weekly, and monthly. Scripts to be executed in said times can be placed in /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/. All scripts in each directory are run as root, and a specific order to running the scripts can be specified by prefixing the scripts’ filenames with numbers (see the man page for run‑parts for more details). Although the directories contain periods in their names, run‑parts will not accept a file name containing a period and will fail silently when encountering them (bug #38022). Either rename the file or use a symlink (without a period) to it instead (see, for example, python + cron without login? and Problems with Hourly Cron Job).

Common Problems

Edits to a user’s crontab and the cron jobs run are all logged by default to /var/log/syslog and that’s the first place to check if things are not running as you expect.

If a user was not allowed to execute jobs when their crontab was last edited, just adding them to the allow list won’t do anything. The user needs to re-edit their crontab after being added to cron.allow before their jobs will run.

Note that user-specific crontabs (including the root crontab) do not specify the user name after the date/time fields. If you accidentally include the user name in a user-specific crontab, the system will try to run the user name as a command.

Cron jobs may not run with the environment, in particular the PATH, that you expect. Try using full paths to files and programs if they’re not being located as you expect.

The «%» character is used as newline delimiter in cron commands. If you need to pass that character into a script, you need to escape it as «%».

If you’re having trouble running a GUI application using cron, see the GUI Applications section below.

Two Other Types of Crontab

The crontab files discussed above are user crontabs. Each of the above crontabs is associated with a user, even the root crontab, which is associated with the root user. There are two other types of crontab, with syntax as follows:

minute(s) hour(s) day(s)_of_month month(s) day(s)_of_week user command

Note that the only difference from the syntax of the user crontabs is that the line specifies the user to run the job as.

The first type is as follows. As mentioned above anacron uses the run‑parts command and /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly directories. However anacron itself is invoked from the /etc/crontab file. This file could be used for other cron commands, but probably shouldn’t be. Here’s an example line from a fictitious /etc/crontab:

00 01 * * * rusty /home/rusty/rusty-list-files.sh

This would run Rusty’s command script as user rusty from his home directory. However, it is not usual to add commands to this file. While an experienced user should know about it, it is not recommended that you add anything to /etc/crontab. Apart from anything else, this could cause a problem if the /etc/crontab file is affected by updates! Rusty could lose his command.

The second type is to be found in the directory /etc/cron.d. This directory can contain crontab files. The directory is often used by packages, and the crontab files allow a user to be associated with the commands in them.

Example: Instead of adding a line to /etc/crontab, which Rusty knows is not a good idea, he might well add a file to the directory /etc/cron.d with the name rusty, containing his cron line above. This would not be affected by updates but is a well known location.

When would you use these alternate crontab locations? Well, on a single user machine or a shared machine such as a school or college server, a user crontab would be the way to go. But in a large IT department, where several people might look after a server, then the directory /etc/cron.d is probably the best place to install crontabs — it’s a central point and saves searching for them!

You may not need to look at /etc/crontab or /etc/cron.d, let alone edit them by hand. But an experienced user should perhaps know about them and that the packages that he/she installs may use these locations for their crontabs.

GUI Applications

It is possible to run gui applications via cronjobs. This can be done by telling cron which display to use.

00 06 * * * env DISPLAY=:0 gui_appname

The env DISPLAY=:0 portion will tell cron to use the current display (desktop) for the program «gui_appname».

And if you have multiple monitors, don’t forget to specify on which one the program is to be run. For example, to run it on the first screen (default screen) use :

00 06 * * * env DISPLAY=:0.0 gui_appname

The env DISPLAY=:0.0 portion will tell cron to use the first screen of the current display for the program «gui_appname».

Note: GUI users may prefer to use gnome-schedule (aka «Scheduled tasks») to configure GUI cron jobs. In gnome-schedule, when editing a GUI task, you have to select «X application» in a dropdown next to the command field.

Note: In Karmic(9.10), you have to enable X ACL for localhost to connect to for GUI applications to work.

 ~$ xhost +local:
non-network local connections being added to access control list
 ~$ xhost
access control enabled, only authorized clients can connect
LOCAL:
...

Crontab Example

Below is an example of how to setup a crontab to run updatedb, which updates the slocate database: Open a terminal, type «crontab -e» (without the double quotes) and press enter. Type the following line, substituting the full path of the application you wish to run for the one shown below, into the editor:

45 04 * * * /usr/bin/updatedb

Save your changes and exit the editor.

Crontab will let you know if you made any mistakes. The crontab will be installed and begin running if there are no errors. That’s it. You now have a cronjob setup to run updatedb, which updates the slocate database, every morning at 4:45.

Note: The double-ampersand (&&) can also be used in the «command» section to run multiple commands consecutively, but only if the previous command exits successfully. A string of commands joined by the double-ampersand will only get to the last command if all the previous commands are run successfully. If exit error-checking is not required, string commands together, separated with a semi-colon (;).

45 04 * * * /usr/sbin/chkrootkit && /usr/bin/updatedb

The above example will run chkrootkit followed by updatedb at 4:45am daily — providing you have all listed apps installed. If chkrootkit fails, updatedb will NOT be run.

How Anacron is Set Up

On Ubuntu 9.10 (and presumably, on later versions), anacron seems to be set up as follows:

There is a Upstart task, located in /etc/init/anacron.conf, which runs all the jobs in /etc/anacrontab. It is set to run on startup.

There is a cron.d file (/etc/cron.d/anacron) which causes the Upstart task to be started every day at 7:30 AM.

There is a file /etc/apm/event.d/anacron, which causes the Upstart task to be started when a laptop is plugged in to A/C power, or woken up.

In the system crontab (/etc/crontab), if anacron is not execuatable, run‑parts is used to run the files in cron.daily, cron.weekly, and cron.monthly at 6:25 AM, 6:47 AM and 6:52 AM, respectively.

In /etc/anacrontab, run‑parts is used to run cron.daily 5 minutes after anacron is started, and cron.weekly after 10 minutes (once a week), and cron.monthly after 15 (once a month).

Within the cron.daily, weekly, and monthly directories ( /etc/cron.daily, etc.) there is a 0anacron file that sets the timestamps for anacron, so it will know they have been run, even if it didn’t run them.

So it appears anacron is run on every startup, wake up, plug-in, and at 7:30 AM every day. Looking at the respective Changelogs and package databases, it looks like this setup is directly from Debian, and hasn’t been changed since at least 2009.

Alternatives to Cron

Some hosting companies don’t allow access to cron, but there are websites offering alternative ways of scheduling jobs (free or paid-for). Here are some examples:

• SetCron

• SetCronJob

• OnlineCronJobs

• EasyCron

Вам нужно регулярно запускать скрипт, но вы не хотите запускать его вручную? Или, может быть, вам нужно выполнить команду в определенное время или интервал, но вы не хотите, чтобы процесс монополизировал ваш процессор или память. В любом случае cron jobs идеально подходят для этой задачи. Давайте посмотрим, что это такое, как их настроить и что с ними можно сделать.

Бывают случаи, когда в будущем необходимо автоматически запускать группу задач в определенное время. Эти задачи обычно являются административными, но могут быть любыми – от создания резервных копий базы данных до загрузки электронных писем, когда все спят.

Cron — это планировщик заданий на основе времени в Unix-подобных операционных системах, который запускает определенные задачи в будущем. Название происходит от греческого слова χρόνος (хронос), что означает время.

Наиболее часто используемая версия Cron известна как Vixie Cron. Пол Викси первоначально разработал его в 1987 году.

Терминология Cron Job

• Job: единица работы, серия шагов, чтобы что-то сделать. Например, отправка электронной почты группе пользователей. В этой статье будет использоваться задача, задание, задание cron или событие взаимозаменяемо.
• Daemon: компьютерная программа, которая работает в фоновом режиме, служа различным целям. Daemon часто запускаются во время загрузки. Веб-сервер — это демон, обслуживающий HTTP-запросы. Cron — это Daemon для выполнения запланированных задач.
• Cron Job: задание cron — это запланированное задание. Daemon запускает задание, когда оно должно быть выполнено.
• Webcron:  планировщик заданий на основе времени, который работает в серверной среде. Это альтернатива стандартному Cron, часто на общих веб-хостах, которые не предоставляют доступ к оболочке.

Начало работы с Cron Jobs

Если мы заглянем внутрь /etc каталога, то увидим такие каталоги, как cron.hourly, cron.daily, cron.weeklyи cron.monthly, каждый из которых соответствует определенной частоте выполнения.

Одним из способов планирования наших задач является размещение наших сценариев в соответствующем каталоге. Например, для db_backup.php ежедневного запуска мы поместили его внутрь cron.daily. Если папка для данной частоты отсутствует, нам нужно будет сначала создать ее.

Этот подход использует run-parts скрипт, команду, которая запускает каждый исполняемый файл, который он находит в указанном каталоге.

Это самый простой способ запланировать задачу. Однако, если нам нужна большая гибкость, мы должны использовать Crontab.

Файлы Crontab

Cron использует специальные файлы конфигурации, называемые crontabфайлами, которые содержат список выполняемых заданий. Crontab означает таблицу Cron. Каждая строка в файле crontab называется заданием cron, которое напоминает набор столбцов, разделенных символом пробела. Каждая строка указывает, когда и как часто Cron должен выполнять определенную команду или сценарий.

В файле crontab пустые строки или строки, начинающиеся с #пробелов или табуляции, будут игнорироваться. Строки, начинающиеся с #, считаются комментариями.

Активные строки в crontab являются либо объявлением переменной среды, либо заданием cron. Crontab не разрешает комментарии к активным строкам.

Ниже приведен пример файла crontab с одной записью:

0 0 * * *  /var/www/sites/db_backup.sh

Первая часть 0 0 * * *— это выражение cron, которое определяет частоту выполнения. Вышеуказанное задание cron будет выполняться один раз в день.

Пользователи могут иметь свои собственные файлы crontab, названные в честь их имени пользователя, зарегистрированного в /etc/passwd файле. Все файлы crontab пользовательского уровня находятся в области spool Cron. Вы не должны редактировать эти файлы напрямую. Вместо этого мы должны редактировать их с помощью утилиты crontab командной строки.

Примечание: Каталог spool варьируется в разных дистрибутивах Linux. На Ubuntu это /var/spool/cron/crontabs в то время как в CentOS это /var/spool/cron.

Чтобы отредактировать наш собственный файл crontab:

crontab -e

Приведенная выше команда автоматически откроет файл crontab, принадлежащий нашему пользователю. Если вы еще не выбрали редактор по умолчанию для crontab, вы увидите набор установленных редакторов для выбора. Мы также можем явно выбрать или изменить нужный нам редактор для редактирования файла crontab:

export VISUAL=nano; crontab -e

После сохранения файла и выхода из редактора crontab будет проверен на точность. Если все настроено правильно, файл будет сохранен в каталоге spool.

Каждая команда в файле crontab выполняется с точки зрения пользователя, которому принадлежит crontab. Если ваша команда выполняется как root (sudo), вы не сможете определить этот crontab из своей учетной записи пользователя, если вы не войдете в систему как root.

Список установленных cron jobs, принадлежащих нашему пользователю:

crontab -l

Мы также можем записать наши задания cron в файл и отправить его содержимое в файл crontab следующим образом:

crontab /path/to/the/file/containing/cronjobs.txt

Предыдущая команда перезапишет существующий файл crontab /path/to/the/file/containing/cronjobs.txt.

Чтобы удалить crontab, мы используем -r опцию:

crontab -r

Анатомия записи Crontab

Анатомия записи crontab на уровне пользователя выглядит следующим образом:

 # ┌───────────── min (0 - 59) 
 # │ ┌────────────── hour (0 - 23)
 # │ │ ┌─────────────── day of month (1 - 31)
 # │ │ │ ┌──────────────── month (1 - 12)
 # │ │ │ │ ┌───────────────── day of week (0 - 6) (0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the same as 0)
 # │ │ │ │ │
 # │ │ │ │ │
 # * * * * *  command to execute

В первых двух полях указывается время (минута и час), в которое будет выполняться задача. Следующие два поля указывают день месяца и месяц. Пятое поле указывает день недели.

Cron выполнит команду, когда минута, час, месяц и день месяца или день недели совпадут с текущим временем.

Если день недели и день месяца имеют определенные значения, событие будет выполняться, когда любое поле соответствует текущему времени. Рассмотрим следующее выражение:

0 0 5-20/5 Feb 2 /path/to/command

Предыдущее задание cron будет выполняться один раз в день каждые пять дней, с 5 по 20 февраля плюс все вторники февраля.

Важно: Когда и день месяца, и день недели имеют определенные значения (не звездочку), он создаст OR условие, то есть оба дня будут совпадать.

Синтаксис в system crontabs (/etc/crontab) немного отличается от crontabs пользовательского уровня. Разница в том, что шестое поле — это не команда, а пользователь, от имени которого мы хотим запустить задание.

* * * * * testuser /path/to/command

Не рекомендуется помещать общесистемные задания cron /etc/crontab, так как этот файл может быть изменен в будущих обновлениях системы. Вместо этого мы помещаем эти задания cron в /etc/cron.d каталог.

Редактирование Crontab других пользователей

Возможно, нам придется редактировать файлы crontab других пользователей. Для этого мы используем -u опцию, как показано ниже:

crontab -u username -e

Примечание Мы можем редактировать файлы crontab других пользователей только как пользователь root или как пользователь с правами администратора.

Некоторые задачи требуют прав администратора. Вы должны добавить их в файл crontab корневого пользователя:

sudo crontab -e

Обратите внимание, что использование sudowith crontab -eбудет редактировать файл crontab корневого пользователя. Если нам нужно отредактировать crontab другого пользователя во время использования sudo, мы должны использовать -u опцию для указания владельца crontab.

Чтобы узнать больше о crontab команде:

man crontab

Стандартные и нестандартные значения Crontab

Поля Crontab принимают числа в качестве значений. Однако мы можем поместить в эти поля и другие структуры данных.

Диапазоны

Мы можем передавать диапазоны чисел:

0 6-18 1-15 * * /path/to/command

Вышеуказанное задание cron будет выполняться с 6 утра до 6 вечера с 1-го по 15-е число каждого месяца в году. Обратите внимание, что указанный диапазон включен, поэтому 1-5 означает 1,2,3,4,5.

Списки

Список — это группа значений, разделенных запятыми. Мы можем иметь списки в качестве значений полей:

0 1,4,5,7 * * * /path/to/command

Приведенный выше синтаксис будет запускать задание cron в 1 am, 4 am, 5 am и 7 am каждый день.

Шаги

Шаги можно использовать с диапазонами или символом звездочки(*). Когда они используются с диапазонами, они указывают количество значений, которые нужно пропустить через конец диапазона. Они определяются «/" символом после диапазона, за которым следует число. Рассмотрим следующий синтаксис:

0 6-18/2 * * * /path/to/command

Вышеуказанное задание cron будет выполняться каждые два часа с 6 утра до 6 вечера.

Когда шаги используются со звездочкой, они просто указывают частоту этого конкретного поля. Например, если мы устанавливаем минуту*/5, это просто означает каждые пять минут.

Мы можем комбинировать списки, диапазоны и шаги вместе, чтобы иметь более гибкое планирование событий:

0 0-10/5,14,15,18-23/3 1 1 * /path/to/command

Вышеуказанное событие будет проходить каждые пять часов с полуночи 1 января до 10 утра, 2 вечера, 3 вечера, а также каждые три часа с 6 вечера до 11 вечера.

Имена

Для полей месяц и день недели мы можем использовать первые три буквы определенного дня или месяца, например Sat, sun, Feb, Sep, и т.д.

* * * Feb,mar sat,sun /path/to/command

Предыдущее задание cron будет выполняться только по субботам и воскресеньям февраля и марта.

Обратите внимание, что имена не чувствительны к регистру. Диапазоны не допускаются при использовании имен.

Предопределенные определения

Некоторые реализации cron могут поддерживать некоторые специальные строки. Эти строки используются вместо первых пяти полей, каждое из которых определяет определенную частоту:

• @annual, @annual Запуск один раз в год в полночь 1 января (0 0 1 1 *)
• @ежемесячный запуск один раз в месяц, в полночь первого дня месяца (0 0 1 * *)
• @еженедельный запуск один раз в неделю в полночь воскресенья (0 0 * * 0)
• @ежедневный запуск один раз в день в полночь (0 0 * * *)
• @почасовой запуск в начале каждого часа (0 * * * *)
• @reboot Запуск один раз при запуске

Несколько команд в одном задании Cron

Мы можем выполнить несколько команд в одном задании cron, разделив их точкой с запятой (;).

* * * * * /path/to/command-1; /path/to/command-2

Если выполняемые команды зависят друг от друга, мы можем использовать двойной амперсанд (&&) между ними. В результате вторая команда не будет выполняться, если первая не выполняется.

* * * * * /path/to/command-1 && /path/to/command-2

Переменные среды

Переменные среды в файлах crontab имеют форму VARIABLE_NAME = VALUE (пробелы вокруг знака равенства необязательны). Cron не создает никаких файлов запуска из домашнего каталога пользователя (когда он работает на уровне пользователя cron). Это означает, что мы должны вручную установить любые пользовательские настройки, требуемые нашими задачами.

Daemon Cron автоматически устанавливает некоторые переменные среды при запуске. HOMEи LOGNAME устанавливаются из информации владельца crontab /etc/passwd в. Однако мы можем переопределить эти значения в нашем файле crontab, если в этом есть необходимость.

Есть также еще несколько переменных, например SHELL, указывающих оболочку, которая выполняет команды. Это /bin/sh по умолчанию. Мы также можем установить PATH, в котором искать программы.

PATH = /usr/bin;/usr/local/bin

Важно: мы должны заключать значение в кавычки, когда в значении есть пробел. Обратите внимание, что значения являются обычными строками. Они не будут интерпретироваться или анализироваться каким-либо образом.

Разные часовые пояса

Cron использует настройку часового пояса системы при оценке записей crontab. Это может вызвать проблемы для многопользовательских систем с пользователями, базирующимися в разных часовых поясах. Чтобы обойти эту проблему, мы можем добавить переменную среды с именем CRON_TZ в наш файл crontab. В результате все записи crontab будут проанализированы на основе указанного часового пояса.

Как Cron интерпретирует файлы Crontab

После запуска Cron он выполняет поиск в области катушки, чтобы найти и загрузить файлы crontab в память. Он дополнительно проверяет /etc/crontab/etc/cron.d каталоги и или для системных crontabs.

После загрузки crontabs в память Cron проверяет загруженные crontabs поминутно, выполняя события, которые должны быть выполнены.

Кроме того, Cron регулярно (каждую минуту) проверяет, изменилось ли modtimeвремя изменения каталога spool. Если это так, он проверяет modetimeвсе загруженные crontabs и перезагружает те, которые изменились. Вот почему нам не нужно перезапускать Daemon при установке нового задания cron.

Разрешения Cron

Мы можем указать, какой пользователь должен иметь возможность использовать Cron, а какой нет. Есть два файла, которые играют важную роль, когда дело доходит до разрешений cron: /etc/cron.allowи /etc/cron.deny.

Если /etc/cron.allow существует, то наше имя пользователя должно быть указано в этом файле для использования crontab. Если /etc/cron.deny существует, он не должен содержать наше имя пользователя. Если ни один из этих файлов не существует, то на основе параметров конфигурации, зависящих от сайта, либо суперпользователь, либо все пользователи смогут использовать crontab команду. Например, в Ubuntu, если ни один файл не существует, все пользователи могут использовать crontab по умолчанию.

Мы можем поместить ALL/etc/cron.deny файл, чтобы запретить всем пользователям использовать cron:

echo ALL > /etc/cron.deny

Примечание: Если мы создаем /etc/cron.allow файл, нет необходимости создавать /etc/cron.deny файл, поскольку он имеет тот же эффект, что и создание /etc/cron.deny файла с ALL в нем.

Перенаправление вывода

Мы можем перенаправить вывод нашего задания cron в файл, если команда (или скрипт) имеет какой-либо вывод:

* * * * * /path/to/php /path/to/the/command >> /var/log/cron.log

Мы можем перенаправить стандартный вывод на dev null, чтобы не получить электронное письмо, но все же отправить стандартное сообщение об ошибке:

* * * * * /path/to/php /path/to/the/command > /dev/null

Чтобы запретить Cron отправлять нам какие-либо электронные письма, мы меняем соответствующую запись crontab, как показано ниже:

* * * * * /path/to/php /path/to/the/command > /dev/null 2>&1

Это означает “отправить как стандартный вывод, так и вывод ошибки в забвение”.

Отправьте вывод по электронной почте

Выходные данные отправляются по почте владельцу crontab или электронной почте (адресам), указанным в переменной MAILTOсреды (если стандартный вывод или стандартная ошибка не перенаправляются, как указано выше).

Если MAILTO установлено значение empty, в результате выполнения задания cron электронное письмо отправлено не будет.

Мы можем установить несколько писем, разделив их запятыми:

MAILTO=admin@example.com,dev@example.com
* * * * * /path/to/command

Cron и PHP

Обычно мы запускаем наши скрипты командной строки PHP, используя исполняемый файл PHP.

php script.php

В качестве альтернативы мы можем использовать shebang в начале скрипта и указать на исполняемый файл PHP:

#! /usr/bin/php

<?php

// PHP code here

В результате мы можем выполнить файл, вызвав его по имени. Тем не менее, мы должны убедиться, что у нас есть разрешение на его выполнение.

Чтобы иметь более надежные скрипты командной строки PHP, мы можем использовать сторонние компоненты для создания консольных приложений, таких как Symfony Console Component или Laravel Artisan. Эта статья является хорошим началом для использования консольного компонента Symfony.

Узнайте больше о создании консольных команд с помощью Laravel Artisan.

Перекрытия задач

Бывают случаи, когда запланированные задачи занимают гораздо больше времени, чем ожидалось. Это приведет к перекрытиям, то есть некоторые задачи могут выполняться одновременно. В некоторых случаях это может не вызвать проблемы, но когда они изменяют одни и те же данные в базе данных, у нас возникнет проблема. Мы можем преодолеть это, увеличив частоту выполнения задач. Тем не менее, нет никакой гарантии, что эти перекрытия не повторятся.

У нас есть несколько вариантов предотвращения перекрытия заданий cron.

Использование Flock

Flock — хороший инструмент для управления файлами блокировки из сценариев оболочки или командной строки. Эти файлы блокировки полезны для того, чтобы узнать, запущен ли скрипт.

При использовании совместно с Cron соответствующие задания cron не запускаются, если файл блокировки существует. Вы можете установить Flock, используя apt-get или yum, в зависимости от дистрибутива Linux.

apt-get install flock

Или:

yum install flock

Рассмотрим следующую запись crontab:

* * * * * /usr/bin/flock --timeout=1 /path/to/cron.lock /usr/bin/php /path/to/scripts.php

В предыдущем примере flock ищет /path/to/cron.lock. Если блокировка будет получена за одну секунду, она запустит скрипт. В противном случае он потерпит неудачу с кодом выхода 1.

Использование механизма блокировки в скриптах

Если задание cron выполняет сценарий, мы можем реализовать механизм блокировки в сценарии. Рассмотрим следующий PHP-скрипт:

<?php
$lockfile = sys_get_temp_dir() . '/' md5(__FILE__) . '.lock';
$pid      = file_exists($lockfile) ? trim(file_get_contents($lockfile)) : null;

if (is_null($pid) || posix_getsid($pid) === false) {

    // Do something here
    
    // And then create/update the lock file
    file_put_contents($lockfile, getmypid());

} else {
    exit('Another instance of the script is already running.');
}

В предыдущем коде мы сохраняем pid текущий PHP-процесс в файле, который находится в системном tempкаталоге. Каждый PHP-скрипт имеет свой собственный файл блокировки, который является MD5-хэшем имени файла скрипта.

Сначала мы проверяем, существует ли файл блокировки, а затем получаем его содержимое, которое является идентификатором процесса последнего запущенного экземпляра скрипта. Затем мы передаем pid PHP-функцию posix_getsid , которая возвращает идентификатор сеанса процесса. Если posix_getsid возвращается false, это означает, что процесс больше не работает, и мы можем безопасно запустить новый экземпляр.

Anacron

Одна из проблем с Cron заключается в том, что он предполагает, что система работает непрерывно (24 часа в сутки). Это вызывает проблемы для машин, которые не работают весь день (например, персональные компьютеры). Если система отключается в течение запланированного времени выполнения задачи, Cron не будет выполнять эту задачу задним числом.

Anacron не является заменой Cron, но решает эту проблему. Он выполняет команды один раз в день, неделю или месяц, но не поминутно или ежечасно, как это делает Cron. Однако это гарантия того, что задача будет выполнена, даже если система отключится на непредвиденный период времени.

Только root или пользователь с правами администратора может управлять задачами Anacron. Anacron не работает в фоновом режиме, как Daemon, а только один раз, выполняя задачи, которые должны быть выполнены.

Anacron использует файл конфигурации (так же, как crontab) с именем anacrontabs. Этот файл находится в /etc каталоге.

Содержимое этого файла выглядит следующим образом:

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

В anacrontab файле мы можем установить частоты только с периодом nдней, за которым следует время задержки в минутах. Это время задержки просто для того, чтобы убедиться, что задачи не выполняются одновременно.

Третий столбец — это уникальное имя, которое идентифицирует задачу в файлах журнала Anacron.

Четвертый столбец — это фактическая команда для запуска.

Рассмотрим следующую запись:

1       5       cron.daily              nice run-parts /etc/cron.daily

Эти задачи выполняются ежедневно, через пять минут после запуска Anacron. Он использует run-partsдля выполнения всех скриптов внутри/etc/cron.daily.

Вторая запись в списке выше выполняется каждые 7 дней (еженедельно) с задержкой 25 минут.

Столкновение между Cron и Anacron

Как вы, наверное, заметили, Cron также настроен на выполнение скриптов внутри /etc/cron.* каталогов. Различные варианты Linux обрабатывают такое возможное столкновение с Anacron по-разному. В Ubuntu Cron проверяет, присутствует ли Anacron в системе, и если это так, он не будет выполнять сценарии в /etc/cron.* каталогах.

В других версиях Linux Cron обновляет временные метки Anacron при выполнении задач. Anacron не будет выполнять их, если Cron уже запустил их.

Быстрое устранение неполадок

Абсолютный путь к командам

Это хорошая привычка использовать абсолютные пути ко всем исполняемым файлам, которые мы используем в файле crontab.

* * * * * /usr/local/bin/php /absolute/path/to/the/command

Убедитесь, что Daemon cron запущен

Если наши задачи вообще не выполняются, сначала нам нужно убедиться, что Daemon Cron запущен:

ps aux | grep crond

Вывод должен быть похож на этот:

root      7481  0.0  0.0 116860  1180 ?        Ss    2015   0:49 crond

Проверка /etc/cron.allowи /etc/cron.deny файлы

Когда задания cron не выполняются, нам нужно проверить /etc/cron.allow, существует ли. Если это так, нам нужно убедиться, что мы перечислили наше имя пользователя в этом файле. И если /etc/cron.deny существует, нам нужно убедиться, что наше имя пользователя не указано в этом файле.

Если мы редактируем файл crontab пользователя, в то время как пользователь не существует в /etc/cron.allow файле, включая пользователя в /etc/cron.allow не будет запускать cron, пока мы не отредактируем файл crontab.

Разрешение на выполнение

Мы должны убедиться, что владелец crontab имеет разрешения на выполнение для всех команд и сценариев в файле crontab. В противном случае cron не будет работать. Вы можете добавить разрешения на выполнение в любую папку или файл с помощью:

chmod +x /some/file.php

Новый символ строки

Каждая запись в crontab должна заканчиваться новой строкой. Это означает, что после последней записи crontab должна быть пустая строка, иначе последнее задание cron никогда не будет выполнено.

Завершение

Cron — это Daemon, выполняющий список событий, запланированных на будущее. Мы определяем эти задания в специальных файлах конфигурации, называемых файлами crontab. Пользователи могут иметь свой собственный файл crontab, если им разрешено использовать Cron на основе /etc/cron.allow или /etc/cron.deny files. В дополнение к заданиям cron на уровне пользователя Cron также загружает общесистемные задания cron, которые немного отличаются по синтаксису.

Наши задачи обычно PHP скрипты или утилиты командной строки. В системах, которые не работают все время, мы можем использовать Anacron для запуска событий, которые происходят в течение nнескольких дней.

При работе с Cron мы также должны знать о задачах, перекрывающих друг друга, чтобы предотвратить потерю данных. После завершения задания cron выходные данные будут отправлены владельцу crontab и/или электронной почты, указанной в переменной MAILTO среды.

Разбираемся с тем, что представляет собой Cron, как он работает и зачем нужен. Пытаемся обуздать его параметры, чтобы планировать задачи на своем сервере без лишних затрат сил и времени.

Что такое Cron и crontab?

Если в двух словах, то Cron – это планировщик задач. Если подробнее, то это утилита, позволяющая выполнять скрипты на сервере в назначенное время с заранее определенной периодичностью.

К примеру, у вас есть скрипт, который собирает какие-либо статистические данные каждый день в 6 часов вечера. Такие скрипты называют «заданиями», а их логика описывается в специальных файлах под названием сrontab.

crontab – это таблица с расписанием запуска скриптов и программ, оформленная в специальном формате, который умеет считывать компьютер. Для каждого пользователя системы создается отдельный crontab-файл со своим расписанием. Эта встроенная в Linux утилита доступна на низком уровне в каждом дистрибутиве.

В Linux-дистрибутивах с поддержкой systemd Cron считается устаревшим решением, его заменили утилитой systemd.timer. Ее предназначение и функциональность не отличается, но фактически частота использования Cron все еще выше.

Для чего обычно используют Cron?

Обычно Cron заставляют повторять вполне очевидные задачи в духе регулярного создания резервных копий данных. Но это не все.

1. Некоторые пользователи с помощью планировщика корректируют системное время. На многих компьютерах оно настраивается через Network Time Protocol. А так как этот протокол настраивает только время ОС, время, установленное для «железа», может отличаться. Cron позволяют регулярно корректировать время, установленное для аппаратного обеспечения, в соответствии со временем ОС.
2. Еще один популярный сценарий – создание оповещений, появляющихся каждое утро и рассказывающих о состоянии компьютера. В эти сообщения может входить любая полезная для пользователя информация.
3. Cron иногда работает даже без ведома пользователя. Эту утилиту используют такие сервисы, как Logwatch, logrotate и Rootkit Hunter. Повторяющиеся задачи они настраивают, как и пользователи, через Cron.

С помощью Cron пользователи автоматизируют самые разные задачи, сокращая вмешательство системного администратора в работу сервера.

Базовые принципы работы с Cron и crontab (через панель управления)

Многие хостинг-провайдеры предлагают отдельное меню в панели управления для настройки расписания запланированного выполнения скриптов.

Разберем подобное меню на примере панели управления Timeweb. Чтобы создать новую задачу, необходимо открыть раздел Crontab в боковой панели веб-интерфейса, кликнуть по кнопке «Добавить новую задачу» и указать параметры повторяющейся команды.​ Поговорим подробнее о параметрах. 

• Сначала надо придумать для команды название (подойдет любой текст без спецсимволов).
• Затем указываем исполнителя (нужно выбрать, будет ли планировщик работать с исполняемым файлом, PHP-скриптом или HTTP-запросом).
• В графе «Путь до файла» вводим абсолютный путь до скрипта, запуск которого хотим запланировать. К примеру: /home/u/myusername/mytestscript.php. При желании можно воспользоваться встроенным файловым менеджером и выбрать заранее предзагруженный на сервер скрипт.
• После этого указываем периодичность выполнения выбранного скрипта или исполняемого файла (в списке доступны предустановки в духе «Каждую минуту» или «Раз в день», но можно выбрать и пункт «Продвинутые настройки»).
• Кликаем по кнопке «Создать задачу».

На этом все. Скрипт запланирован и будет регулярно повторяться.

Базовые принципы работы с Cron и crontab (через SSH-протокол)

Планировать задачи через панель управления удобно, но не всегда возможно. Не все хостинг-провайдеры предлагают такие функциональные веб-интерфейсы. В этом случае придется воспользоваться командной строкой, подключившись к серверу по протоколу Secure Shell.

Для работы с планировщиком в системе есть ряд команд, помогающих решать основные задачи:

• crontab -e – открывает конфигурационный файл (поговорим о нем чуть подробнее в разделе с первичной настройкой).
• crontab -l – показывает список задач из конфигурационного файла (все, что было запланировано).
• crontab -r – удаляет конфигурационный файл вместе со всеми запланированными задачами.
• сrontab -v – показывает, когда в последний раз открывался конфигурационный файл.

Чтобы запланировать задачи, используя командную строку, необходимо выполнить базовую настройку Cron, проверить, не установлены ли ограничения, и заполнить расписание задач в соответствии с синтаксисом сrontab.

Первичная настройка Cron

Как мы уже выяснили ранее, планировщик черпает параметры для выполнения своих задач из crontab-файлов (таблиц с расписанием). У каждого пользователя, включая root, должен быть свой crontab-файл. По умолчанию он не существуют, поэтому придется создать его вручную.

Для этого существует команда crontab -e. Она автоматически генерирует таблицу в директории /var/spool/cron.

Вновь созданный файл будет пустым текстовым полем. Необходимо добавлять в него все параметры самостоятельно с нуля, опираясь на синтаксис сrontab (более подробно поговорим о нем ниже). После ввода параметров нужно сохранить параметры редактора, нажав на клавишу F2, а затем покинуть конфигурационный файл, нажав на клавишу F10. При введении корректных параметров в терминале отобразится строка crontab: installing new crontab.

Опытные разработчики и системные администраторы не рекомендуют использовать для редактирования расписания текстовые редакторы в духе Nano, Emacs или Vi. Команды crontab позволяют не только внести изменения в таблицу запланированных задач, но и перезапустить фоновый процесс crond, отвечающий за работу утилиты после сохранения настроек.

Ограничения Cron

У Cron есть функция установки ограничений на использование, задающихся через два специальных файла: cron.allow и cron.deny.

Первый файл находится в директории /usr/lib/cron/cron.allow и содержит в себе список учетных записей (имен пользователей), которые имеют право на планирование задач с помощью встроенных системных утилит.

Второй файл находится в директории /usr/lib/cron/cron.deny. В нем указываются имена пользователей, которые не могут запускать встроенный в систему планировщик задач.

Если первого файла не существует, то любой пользователь может планировать задачи с помощью встроенного в систему планировщика, но только при условии, что его имени нет во втором файле. Если удалить оба файла, то каждый пользователь сможет планировать задачи без ограничений.

Синтаксис crontab

# crontab -e
SHELL=/bin/bash
MAILTO=mymail@someprovider.com
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

# Детали смотрите в следующих разделах

# Примеры оформления задач в планировщике (формат данных):
# .---------------- минуты (0 - 59)
# |  .------------- часы (0 - 23)
# |  |  .---------- дни месяца (1 - 31)
# |  |  |  .------- сами месяцы (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- дни недели (0 - 6) (0 или 7 это воскресенье в зависимости от настроек системы) можно использовать сокращения типа mon,tue,wed,thu,fri,sat,sun
# |  |  |  |  |
# *  *  *  *  * имя пользоваться  команда, которую нужно запустить

# создание копии всей операционной системы с помощью кастомного скрипта 
01 01 * * * /usr/local/bin/bckp -vbd1 ; /usr/local/bin/bckp -vbd2

# установка соответствия между временем операционной системы и "железа"
03 05 * * * /sbin/hwclock --systohc

# проведение обновления операционной системы в заданный период времени
25 04 1 * * /usr/bin/apt-get update

Первые три линии кода в таблице отвечают за первичную настройку. Сначала указывается оболочка, в которой будет работать Cron. У утилиты нет каких-либо предпочтений, поэтому можно указать любую на собственное усмотрение (в нашем примере это bash). Затем указывается адрес электронный почты, на который будут отправляться отчеты о работе планировщика. И напоследок указывается путь к окружению.

Ниже находятся параметры, используемые для запуска процессов в определенный период времени. В комментариях описан базовый синтаксис, включающий в себя формат времени, имя пользователя и команду, которая должна быть запущена.

В нашем случае указаны команды:

02 04 5 * * /usr/local/bin/bckp -vbd1 ; /usr/local/bin/bckp -vbd2
04 06 * * * /sbin/hwclock –systohc
10 05 5 * * /usr/bin/apt-get update
05 * * * * rm /home/myusername/tmp/*

Примеры использования Cron в командной строке

Команда

02 04 5 * * /usr/local/bin/bckp -vbd1 ; /usr/local/bin/bckp -vbd2

создает в таблице расписания задачу на запуск скрипта под названием bckp (представим, что такой существует), который создает резервную копию всей системы на стороннем накопителе. Он выполняется 5 числа каждого месяца в 4 часа 2 минуты утра. Это видно по числовым значениям. Звездочки же указывают на отсутствие конкретного значения. Cron воспринимает их как «выполнять каждый раз», то есть каждый месяц, день или неделю.

Команда

04 06 * * * /sbin/hwclock –systohc

меняет время аппаратного обеспечения на то, что используется в системе. Делает это каждый день, каждую неделю и каждый месяц в 6 часов 4 минуты утра. Как видите, здесь пропущено третье значение. Поэтому команда и запускается ежедневно, так как нет более конкретных правил.

Команда

10 05 5 * * /usr/bin/apt-get update

запускает обновление пакетов с помощью пакетного менеджера apt каждый месяц 5 числа в 05:10.

Команда

05 * * * * rm /home/myusername/tmp/*

удаляет содержимое папки с временными файлами для конкретного пользователя (меня) на пятой минуте (первый пункт) каждого часа. Так как определенные значения отсутствуют для всех остальных пунктов, получается, что скрипт готов выполняться каждый день, каждый месяц и каждый час. Но первое значение указано, поэтому он будет дожидаться пятой минуты и запускаться в этот момент. То есть в 12:05, 13:05, 14:05 и т.п.

Как видите, разобраться с базовыми командами несложно.

Другие примеры настройки Cron

На примере команды для удаления временных файлов разберем пару-тройку нестандартных настроек расписания.

К примеру, некоторые показатели можно вводить не в виде цифр, а в виде сокращенных слов. Чтобы запускать удаление временных файлов каждую пятницу в 4 часа вечера, необходимо ввести в crontab:

00 16 * * Fri rm /home/myusername/tmp/*

Если не указывать в планировщике точных вводных, то выбранный скрипт будет выполняться каждую минуту:

* * * * * rm /home/myusername/tmp/*

Можно заставить планировщик выполнять задачу только в определенные месяцы. Чтобы запускать удаление временных файлов 1 февраля, 1 мая и 1 сентября в половину первого ночи, необходимо ввести в crontab:

30 00 1 2,5,9 * * rm /home/myusername/tmp/*

Некоторые скрипты необходимо выполнять только по будням, поэтому в Cron есть возможность исключить некоторые дни недели из расписания:

00 16 * * 1–5 rm /home/myusername/tmp/*

Часы тоже можно делить. Например, запускать ту или иную задачу каждые 3 часа. Для этого нужно поставить слэш в графе с установкой времени по часам:

*/5 */2 * * * rm /home/myusername/tmp/*

Вместо заключения

О работе с Cron стоит знать еще пару важных вещей.

Во-первых, всегда указывайте корректный почтовый адрес в параметрах. Это позволит собирать информацию о запускаемых по расписанию задачах. В этих письмах содержится и информация о возникающих ошибках. Во-вторых, при указании «исполнителя» в панели управления Timeweb важно делать корректный выбор, чтобы он соответствовал запускаемой задаче. В-третьих, информацию о работе Cron можно собирать в отдельный файл с помощью команд в духе:

30 18 * * * rm /home/myusername/tmp/* > /home/myusername/cronlogs/clean_tmp_dir.log

На этом все. Следуйте инструкциям, не путайте порядок параметров и внимательно изучайте журнал ошибок, если что-то пойдет не так. После недолгой практики вы поймете, что работать с Cron не так уж и сложно!