Настройка Cron
Системным администраторам, да и обычным пользователям часто приходится автоматизировать различные задачи по обслуживанию и работе с Linux с помощью скриптов. Это очень удобно, вы просто запускаете скрипт, и он делает все что необходимо без вашего вмешательства. Следующий шаг в этом пути — настроить автоматически запуск нужного скрипта в нужное время.
Именно для этих задач в Linux используется системный сервис cron. Это планировщик, который позволяет выполнять нужные вам скрипты раз в час, раз в день, неделю или месяц, а также в любое заданное вами время или через любой интервал. Программа часто используется даже другими службами операционной системы. В этой статье мы рассмотрим как выполняется настройка Cron и разберем основные часто используемые примеры.
Как работает Cron?
Фактически, Cron — это сервис, как и большинство других сервисов Linux, он запускается при старте системы и работает в фоновом режиме. Его основная задача выполнять нужные процессы в нужное время. Существует несколько конфигурационных файлов, из которых он берет информацию о том что и когда нужно выполнять. Сервис открывает файл /etc/crontab, в котором указаны все нужные данные. Часто, в современных дистрибутивах там прописан запуск утилиты run-parts, которая запускает нужные скрипты из следующих папок:
- /etc/cron.minutely — каждую минуту;
- /etc/cron.hourly — каждый час;
- /etc/cron.daily — каждый день;
- /etc/cron.weekly — каждую неделю;
- /etc/cron.monthly — каждый месяц.
В этих папках должны находиться скрипты, которые нужно выполнять с указанным интервалом. Скрипты должны иметь права на выполнение и их имя не должно содержать точки. Это очень сильно облегчает работу с планировщиком для новых пользователей. Также в файле crontab прописан запуск команды anacron, которая работает так же как и cron, только предназначена для задач, которые нужно выполнять раз в длительный период, например, раз в день, неделю, месяц, год.
Она позволяет выполнять их даже если компьютер работает не всегда и время от времени выключается. Дата выполнения задания последний раз записывается в файл /var/spool/anacron, а затем, при следующем запуске anacron проверяет был ли запущен нужный процесс в нужное время, и если нет, то запускает его. Сам же сервис cron больше рассчитан на выполнение задач в течение дня или с точно расписанным временем и датой.
Настройка Cron
Для настройки времени, даты и интервала когда нужно выполнять задание используется специальный синтаксис файла cron и специальная команда. Конечно, вы всегда можете отредактировать файл /etc/crontab, но этого делать не рекомендуется. Вместо этого, есть команда crontab:
Ее всегда желательно выполнять с опцией -e, тогда для редактирования правил будет использован ваш текстовый редактор по умолчанию. Команда открывает вам временный файл, в котором уже представлены все текущие правила cron и вы можете добавить новые. После завершения работы команды cron файл будет обработан и все правила будут добавлены в /var/spool/cron/crontabs/имя_пользователя причем добавленные процессы будут запускаться именно от того пользователя, от которого вы их добавляли.
Поэтому тут нужно быть аккуратным, и если вам нужно выполнять скрипты от рута, то и crontab нужно выполнить от рута, а не от пользователя. Это часто становится причиной проблем.
Синтаксис crontab
Как я уже говорил, время задается особым синтаксисом, давайте рассмотрим синтаксис настройки одной задачи cron:
минута час день месяц день_недели /путь/к/исполняемому/файлу
Нужно сказать, что обязательно нужно писать полный путь к команде, потому что для команд, запускаемых от имени cron переменная среды PATH будет отличаться, и сервис просто не сможет найти вашу команду. Это вторая самая распространенная причина проблем с Cron. Дата и время указываются с помощью цифр или символа ‘*’. Этот символ означает, что нужно выполнять каждый раз, если в первом поле — то каждую минуту и так далее. Ну а теперь перейдем к примерам.
Примеры настройки cron
Сначала можно посмотреть задачи cron для суперпользователя, для этого можно воспользоваться опцией -l:
Вы можете удалить все существующие задачи командой -r:
Давайте предположим, что нам нужно запускать от имени суперпользователя наш скрипт по адресу /usr/local/bin/serve. Какой-нибудь обслуживающий скрипт. Самый простой пример — запускать его каждую минуту:
Далее, усложним, будем запускать каждый час, в нулевую минуту:
Запускаем в нулевую минуту нулевого часа, каждый день, это в 12 ночи:
Если идти так дальше, то можно запускать в первый день каждого месяца:
Можно в любой день, например, 15 числа:
0 0 15 * * /usr/local/bin/serve
В первый день недели первого месяца года, 0 часов 0 минут:
0 0 * 1 0 /usr/local/bin/serve
Или в нулевой день недели каждого месяца:
Вы можете выбрать любую минуту, час и день недели, например, 15.30 во вторник:
30 15 * * 2 /usr/local/bin/serve
Понедельник считается первым днем, воскресенье — это седьмой или нулевой день. Еще можно писать сокращенное название дня недели, например sun — воскресенье:
30 15 * * sun /usr/local/bin/serve
Для того чтобы указать определенный интервал нужно использовать символ «-«, например, каждый час, с семи утра до семи вечера:
0 7-19 * * * /usr/local/bin/serve
Если нужно запустить команду несколько раз, можно использовать разделитель «,». Например, запустим скрипт в 5 и 35 минут пятого (16:05 и 16:35), каждый день:
5,35 16 * * * /usr/local/bin/serve
Вы можете захотеть не указывать отдельно время, а просто указать интервал, с которым нужно запускать скрипт, например, раз в 10 минут. Для этого используется разделитель косая черта — «/»:
Кроме того, для некоторых часто используемых наборов были придуманы переменные, вот они:
- @reboot — при загрузке, только один раз;
- @yearly, @annually — раз год;
- @monthly — раз в месяц;
- @weekly — раз в неделю;
- @daily, @midnight — каждый день;
- @hourly — каждый час.
Например, вот так просто будет выглядеть команда запуска скрипта раз в час:
Если же вы собрались добавить скрипт в одну из папок, то, как я уже говорил, нужно чтобы его имя было без точек и у него были права на выполнение:
sudo vi /etc/corn.daily/backup
Скрипт должен выглядеть подобным образом. Теперь вы знаете как настроить cron, осталось проверить как все работает.
Отладка работы
После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим лог cron. Иногда он находится в /var/log/cron, а иногда пишется в syslog. Например, у меня в crontab есть такая строка:
Она должна выполняться в 19.40 каждый день, теперь смотрим лог:
И видим что в нашем логе она действительно есть и выполняется целиком успешно. Если бы были какие-либо ошибки, то тут же было бы выведено сообщение.
Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:
sudo run-paths /etc/cron.daily/
Дальше вы увидите весь вывод, включая вывод скрипта и сможете быстро понять в чем проблема.
Выводы
В этой статье мы рассмотрели как выполняется настройка cron для удобного планирования автоматических задач. Надеюсь, эта информация была полезной для вас.
Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.
Location of the crontab file
as many (most?) others, I edit my crontab via crontab -e , where I keep all routine operations such as incremental backup, ntpdate, various rsync operations, as well as making my desktop background christmas themed once a year. From what I’ve understood, on a fresh install or new user, this also automatically creates the file if it doesn’t exist. However, I want to copy this file to another user, so where is the actual file that I’m editing? If this varies between distros, I’m using Centos5 and Mint 17
2 Answers 2
The location of cron files for individual users is /var/spool/cron/crontabs/ .
From man crontab :
Each user can have their own crontab, and though these are files in /var/spool/cron/crontabs , they are not intended to be edited directly.
The key words there are «they are not intended to be edited directly», so this answer is incomplete without Celada’s command below, which provides a safer answer to the «copy to another user» portion of the question. If people get in the habit of directly editing crontabs without submitting them through the crontab command, they forego a lot of sanity-checking the command provides.
@MontyHarder I agree «they are not intended to be edited directly» but what if there is a need of it, like there is a need to make an entry in the crontab via a bash script. you have to use the exact file, I don’t think any external interface will help in that case, correct me if I am wrong.
@PrabhatKumarSingh You still shouldn’t directly edit the file. If you read Celada’s command below, you’d have seen an example of how a script could manipulate a crontab file without directly editing it. man crontab explains how this works.
heemayl is correct about the location of crontab files on Linux, but it might be different on other operating systems and «theoretically» is could also be in a different location on Linux. Essentially, when a special interface is provided to access the files, you should use it. This will ensure that cron gets to check the files before installing them, makes sure the files have the permissions it needs them to have, etc.
Therefore you should copy a crontab from one user to another using that interface, like this, not by accessing the files directly.
There are many good reasons why crontab files should not be directly manipulated by anything other than the OS itself. This is a far better solution. I really think it needs to be incorporated into the official answer.
@MontyHarder There isn’t really an «official» answer. There is the answer the person asking chose as personally useful to him/her (the one with the checkmark) and the answer the community chose (with the most upvotes). In short, you have 15 rep, you can suggest this is the right answer by upvoting it. Also, if you want to suggest improvements to the other answer, you need to comment on that answer—otherwise, its author won’t be notified of your comment.
The corollary of this answer is that one should redirect the output of crontab -l to a file, move the file to the other system, and pipe it to crontab . Or maybe even do it directly ( crontab -l | ssh $remote_host crontab ).
«when a special interface is provided to access the files, you should use it.» Imagine every application provided a special interface for editing config files instead of just exposing them through the fs, though. That would be quite the annoyance to keep track of.
As the original asker, I think I should perhasp weigh in on this: The accepted answer was chosen on the basis of my question in its literal sense; the location of the file. My intentions for that file is irrelevant. I don’t think editing in the additional info changes the answer, but it might be considered superfluous.
Where is the user crontab stored?
Since upgrading my user’s crontab has been wiped out. This is not the first time this has happened this year and it’s a pain restoring it each time. I’d like to be able to back up the crontab for my user but for that I need to know where it’s stored.
@WalterTross Yeah it’s quite annoying. I would guess it’s a side-effect of updating the cron package but I agree — it’s not something that should happen.
Just want to mention that there are instructions here about how to reconstruct an accidentally deleted crontab using logs: superuser.com/questions/384109/crontab-deleted It’s not really what you were asking but it might be of use to someone.
4 Answers 4
Actually, it’s not recommended to handle those files by hand. Per crontab man page:
Each user can have their own crontab, and though
these are files in /var/spool/cron/crontabs , they are not
intended to be edited directly.
Files under /var/spool are considered temporary/working, that’s why they probably get deleted during an upgrade, though a closer look at the cron package’s upgrade scripts may shed some light on this.
Anyway, it’s always a good practice to back up your cron entries or keep them in a file in your home directory.
I assume you’re using crontab -e to create crontab files on the fly. If so, you can get a «copy» of your crontab file by doing crontab -l . Pipe that to a file to get a «backup»:
Then you can edit that my-crontab file to add or modify entries, and then «install» it by giving it to crontab:
This does the same syntax checking as crontab -e .