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.
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:
Использование Cron для автоматизации задач в Ubuntu 18.04
Cron — это хронологический демон-планировщик задач, работающий в операционных системах типа Unix, включая дистрибутивы Linux. Cron запускается в фоновом режиме, а задачи, запланированные в cron и именуемые «задачи cron», выполняются автоматически, что делает cron полезным для автоматизации связанных с обслуживанием задач.
В этом обучающем руководстве вы познакомитесь с тем, как планировать задачи с помощью специального синтаксиса cron. Также мы рассмотрим несколько комбинаций клавиш, которые вы можете использовать при создании расписаний задач, чтобы их проще было писать и понимать.
Предварительные требования
Для выполнения этого обучающего руководства вам потребуется доступ к компьютеру с Ubuntu 18.04. Это может быть ваш локальный компьютер, виртуальная машина или виртуальный приватный сервер.
Независимо от того, какой компьютер вы используете для выполнения этого обучающего руководства, у вас должен быть пользователь без привилегий root с настроенными правами администратора. Чтобы выполнить настройку, воспользуйтесь руководством по начальной настройке сервера Ubuntu 18.04.
Установка cron
Почти все дистрибутивы Linux имеют ту или иную форму cron, установленную по умолчанию. Но если вы используете компьютер Ubuntu, где cron не установлен, вы можете установить его с помощью APT.
Перед установкой cron на компьютер Ubuntu обновите локальный индекс пакетов компьютера:
Затем выполните установку cron с помощью следующей команды:
Вам также нужно убедиться, что он настроен для работы в фоновом режиме:
После этого cron будет установлен в системе, а вы сможете начать составлять расписание задач.
Как работает Cron
Задачи в cron записываются и управляются в специальном файле crontab . Каждый профиль пользователя в системе может иметь собственный файл crontab, где составляются расписания задач, которые хранятся в /var/spool/cron/crontabs/ .
Чтобы запланировать задачу, вам нужно открыть ваш файл crontab для редактирования и добавления задачи, написанной в форме выражения cron. Синтаксис выражений cron можно разбить на два элемента: расписание и команда для запуска.
Команда может быть практически любой командой, которую вы можете запустить в командной строке. Компонент расписания в синтаксисе разбит на 5 разных полей, которые расположены в следующем порядке:
| Поле | Допустимые значения |
|---|---|
| минута | 0–59 |
| час | 0–23 |
| День месяца | 1–31 |
| месяц | 1–12 или ЯНВ–ДЕК |
| День недели | 0–6 или ПНД–ВСК |
Все вместе задачи, запланированные в crontab, выглядят следующим образом:
Ниже представлен функциональный пример выражения cron. Это выражение запускает команду curl http://www.google.com каждый вторник в 17:30:
Также существует несколько специальных символов, которые вы можете включить в компонент расписания выражения cron, что упрощает создание расписания:
- * : в выражениях cron звездочка (*) служит подстановочным символом, который представляет все значения. Таким образом, задача, запланированная в форме * * * * * . , будет запускаться каждую минуту, каждый час, каждый день каждого месяца.
- , : запятые разбивают значения расписания для получения списка. Если вы хотите запускать задачу в начале и середине каждого часа, а не выполнять две отдельные задачи (например, 0 * * * * . и 30 * * * * . ), вы можете добиться той же функциональности с помощью одного выражения ( 0,30 * * * * . ).
- — : дефис представляет диапазон значений в поле расписания. Вместо создания 30 отдельных запланированных задач для команды, которую вы хотите запускать первые 30 минут каждого часа (например, 0 * * * * . , 1 * * * * . , 2 * * * * . и т. д.), вы можете просто запланировать его следующим образом: 0-29 * * * * . .
- / : вы можете использовать косую черту со звездочкой для выражения значения шага. Например, вместо написания восьми отдельных задач cron для запуска команды каждые три часа (например, 0 0 * * * . , 0 3 * * * . , 0 6 * * * . и т. д.), вы можете задать расписание для запуска следующим образом: 0 */3 * * * . .
Примечание. Вы не можете выражать значения шага произвольно, допускается использование только целых чисел, которые равномерно делят диапазон, допустимый для данного поля. Например, в поле «часы» вы можете указать после косой черты только 1 , 2 , 3 , 4 , 6 , 8 или 12 .
Ниже представлено несколько примеров использования компонента расписания cron:
- * * * * * — запускать команду каждую минуту.
- 12 * * * * — запускать команду 12 минут в начале каждого часа.
- 0,15,30,45 * * * * — запускать команду каждые 15 минут.
- */15 * * * * — запускать команду каждые 15 минут.
- 0 4 * * * — запускать команду каждый день в 4:00.
- 0 4 * * 2-4 — запускать команду каждый вторник, среду и четверг в 4:00.
- 20,40 */8 * 7-12 * — запускать команду в 20-ю и 40-ю минуту каждого 8-го часа каждый день последних 6 месяцев года.
Если вы найдете что-то из этого затруднительным или вам потребуется помощь при написании расписания для ваших собственных задач cron, Cronitor предоставляет удобный редактор выражений cron, который называется Crontab Guru и который вы можете использовать для проверки действительности ваших расписаний cron.
Управление файлами crontab
После настройки расписания и определения задания, которое нужно запустить, вам нужно будет поместить его в место, где ваш демон сможет его прочитать.
Как уже упоминалось выше, crontab — это специальный файл, где содержится расписание задач, которые cron будет запускать. Однако эти данные не предназначены для редактирования напрямую. Вместо этого рекомендуется использовать команду crontab . Она позволяет изменять файл crontab вашего профиля без внесения изменений в ваши права с помощью sudo . Команда crontab также позволит вам понять, есть ли в crontab ошибки синтаксиса, независимо от того, редактируете вы его или нет.
Вы можете изменить файл crontab с помощью следующей команды:
Если вы впервые запускаете команду crontab в этом профиле пользователя, вы сможете выбрать используемый по умолчанию текстовый редактор для использования при редактировании crontab:
Введите число, соответствующее нужному вам редактору. Кроме того, вы можете просто нажать ENTER , чтобы использовать вариант по умолчанию, nano .
После выбора вы попадете в новый файл crontab, содержащий ряд закомментированных инструкций по его использованию:
При запуске crontab -e в следующий раз, ваш файл будет автоматически открываться в этом текстовом редакторе. После входа в редактор вы можете ввести свое расписание для каждой задачи в новой строке. В противном случае вы можете сохранить изменения и закрыть файл crontab ( CTRL + X , Y , а затем ENTER , если вы выбрали nano ).
Примечание. В системах Linux имеется другой файл crontab, сохраненный в директории /etc/ . Это системный файл crontab, где имеется дополнительное поле, определяющее, для какого профиля пользователя должна запускаться каждая команда cron. В этом обучающем руководстве мы будем использовать файл crontab для конкретного пользователя, но если вы хотите изменить системный файл crontab, вы можете сделать это с помощью следующей команды:
Если вы хотите просмотреть содержимое файла crontab, не изменяя его, вы можете использовать следующую команду:
Вы можете стереть файл crontab с помощью следующей команды:
Предупреждение. Следующая команда не будет запрашивать подтверждение того, что вы хотите стереть ваш файл crontab. Используйте ее, если вы уверены, что хотите стереть его.
Эта команда удаляет файл crontab пользователя немедленно. Однако вы можете включить флаг -i , чтобы добавить в команду подтверждение того, что вы действительно хотите удалить пользовательский файл crontab:
После получения запроса вы должны ввести y , чтобы удалить файл crontab, или n , чтобы отменить удаление.
Управление выводом задачи cron
Поскольку задачи cron выполняются в фоновом режиме, не всегда очевидно, что они были запущены успешно. Теперь, когда вы знаете, как использовать команду crontab и как запланировать задачу cron, вы можете начать экспериментировать с различными способами перенаправления результатов выполнения задач cron, чтобы помочь вам отследить их успешное выполнение.
Если у вас есть агент передачи почты, например, Sendmail, который установлен и настроен на сервере, вы можете отправить результат выполнения задачи cron на электронный адрес, связанный с вашим профилем пользователя Linux. Также вы можете вручную задать адрес электронной почты, указав параметр MAILTO вверху crontab.
Например, вы можете добавить следующие строки в файл crontab. К ним относятся оператор MAILTO , за которым следует пример адреса электронной почты, директива SHELL , которая указывает оболочку для запуска (в данном примере bash ), директива HOME , указывающая путь поиска бинарного файла cron, и единственная задача cron:
Эта конкретная задача будет возвращать «Run this command every minute», а этот вывод будет отправляться каждую минуту на адрес электронной почты, заданный директивой MAILTO .
Также вы можете перенаправить вывод задачи cron в файл журнала или в пустую директорию, чтобы не получать электронное сообщение с выводом.
Чтобы добавить вывод запланированной команды в файл журнала, добавьте >> в конец команды, после чего укажите имя и расположение файла журнала, как показано здесь:
Скажем, что мы хотим использовать cron для запуска скрипта, но скрипт при этом должен выполняться в фоновом режиме. Для этого вы можете перенаправить вывод скрипта в пустую директорию, например /dev/null , которая немедленно удаляет все данные, добавляемые в нее. Например, следующая команда cron выполняет скрипт PHP и запускает его в фоновом режиме:
Эта задача cron также перенаправляет стандартную ошибку — представляемую как 2 — в стандартный вывод ( >&1 ). Поскольку стандартный вывод уже перенаправляется в директорию /dev/null , это позволяет запускать скрипт без лишнего шума. Даже если в crontab содержится оператор MAILTO , вывод команды не будет отправляться на заданный адрес электронной почты.
Ограничение доступа
Вы можете управлять тем, каким пользователям разрешается использовать команду crontab , с помощью файлов cron.allow и cron.deny , которые хранятся в директории /etc/ . Если файл cron.deny существует, любой пользователь, который будет указан в нем, не будет иметь возможность менять файл crontab. Если cron.allow существует, то только пользователи, указанные в нем, будут иметь возможность изменять файлы crontab. Если оба файла существуют, и пользователь указан в каждом файле, файл cron.allow будет иметь приоритет над cron.deny , и этот пользователь сможет изменять файл crontab.
Например, чтобы запретить доступ для всех пользователей, а затем предоставить доступ пользователю ishmael, вы можете использовать следующую последовательность команд:
Сначала мы закрываем доступ для всех пользователей, добавив ALL в файл cron.deny . Затем, добавив имя пользователя в файл cron.allow , мы предоставим пользователю ishmael доступ к выполнению задач cron.
Обратите внимание, что если пользователь имеет права sudo , он может изменять файл crontab другого пользователя с помощью следующей команды:
Однако, если cron.deny существует, и user добавлен в него, но не указан в файле cron.allow , вы получите следующую ошибку после запуска предыдущей команды:
По умолчанию большинство демонов cron полагает, что все пользователи имеют доступ к cron, если только не существует cron.allow или cron.deny .
Специальный синтаксис
Существует также несколько коротких команд, которые вы можете использовать в файле crontab, чтобы упростить процесс создания расписания задач. Они являются эквивалентом для указанных примеров числового расписания:
| Сокращение | Краткая запись для |
|---|---|
| @hourly | 0 * * * * |
| @daily | 0 0 * * * |
| @weekly | 0 0 * * 0 |
| @monthly | 0 0 1 * * |
| @yearly | 0 0 1 1 * |
Примечание. Не все демоны cron могут понимать этот синтаксис (в частности, более ранние версии), поэтому рекомендуем убедиться в этом, прежде чем широко использовать подобный синтаксис.
Кроме того, краткая запись @reboot будет запускать любую команду, которая следует за ней при каждом запуске сервера:
Использование этих комбинаций при возможности поможет понимать расписание задач в вашем файле crontab.
Заключение
Cron — это гибкая и мощная утилита, которая позволяет снизить количество ресурсов, затрачиваемых на администрирование системы. Используя cron вместе со скриптами оболочки, вы можете автоматизировать задачи, которые обычно вызывают затруднения. Например, вы можете написать скрипт оболочки для отправки резервных копий данных решению хранилища объектов и затем автоматизировать его с помощью cron.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Cron в Linux: история, использование и устройство
Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.
Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.
Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.
Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!
Содержание
Происхождение видов
Периодическое выполнение пользовательских или системных программ — очевидная необходимость во всех операционных системах. Поэтому потребность в сервисах, позволяющих централизованно планировать и выполнять задачи, программисты осознали очень давно.
Unix-подобные операционные системы ведут свою родословную от Version 7 Unix, разработанной в 70-х годах прошлого века в Bell Labs в том числе и знаменитым Кеном Томпсоном (англ. Ken Thompson). Вместе c Version 7 Unix поставлялся и cron, сервис для регулярного выполнения задач суперпользователя.
Типичный современный cron — несложная программа, но алгоритм работы оригинального варианта был ещё проще: сервис просыпался раз в минуту, читал табличку с задачами из единственного файл (/etc/lib/crontab) и выполнял для суперпользователя те задачи, которые следовало выполнить в текущую минуту.
Впоследствии усовершенствованные варианты простого и полезного сервиса поставлялись со всеми Unix-подобными операционными системами.
Обобщённые описания формата crontab и базовых принципов работы утилиты в 1992 году были включены в главный стандарт Unix-подобных операционных систем — POSIX — и таким образом cron из стандарта де-факто стал стандартом де-юре.
В 1987 году Пол Викси (англ. Paul Vixie), опросив пользователей Unix на предмет пожеланий к cron, выпустил ещё одну версию демона, исправляющую некоторые проблемы традиционных cron и расширяющую синтаксис файлов-таблиц.
К третьей версии Vixie cron стал отвечать требованиям POSIX, к тому же у программы была либеральная лицензия, вернее не было вообще никакой лицензии, если не считать пожеланий в README: гарантий автор не даёт, имя автора удалять нельзя, а продавать программу можно только вместе с исходным кодом. Эти требования оказались совместимы с принципами набиравшего в те годы популярность свободного ПО, поэтому некоторые ключевые из появившихся в начале 90-х дистрибутивов Linux взяли Vixie cron в качестве системного и развивают его до сих пор.
В частности, Red Hat и SUSE развивают форк Vixie cron — cronie, а Debian и Ubuntu используют оригинальное издание Vixie cron со множеством патчей.
Давайте для начала познакомимся с описанной в POSIX пользовательской утилитой crontab, после чего разберём расширения синтаксиса, представленные в Vixie cron, и использование вариаций Vixie cron в популярных дистрибутивах Linux. И, наконец, вишенка на торте — разбор устройства демона cron.
POSIX crontab
Если оригинальный cron всегда работал для суперпользователя, то современные планировщики чаще имеют дело с задачами обычных пользователей, что более безопасно и удобно.
Сron-ы поставляются комплектом из двух программ: постоянно работающего демона cron и доступной пользователям утилиты crontab. Последняя позволяет редактировать таблицы задач, специфичные для каждого пользователя в системе, демон же запускает задачи из пользовательских и системной таблиц.
В стандарте POSIX никак не описывается поведение демона и формализована только пользовательская программа crontab. Существование механизмов запуска пользовательских задач, конечно, подразумевается, но не описано подробно.
Вызовом утилиты crontab можно сделать четыре вещи: отредактировать пользовательскую таблицу задач в редакторе, загрузить таблицу из файла, показать текущую таблицу задач и очистить таблицу задач. Примеры работы утилиты crontab:
При вызове crontab -e будет использоваться редактор, указанный в стандартной переменной окружения EDITOR .
Сами задачи описаны в следующем формате:
Первые пять полей записей: минуты [1..60], часы [0..23], дни месяца [1..31], месяцы [1..12], дни недели [0..6], где 0 — воскресенье. Последнее, шестое, поле — строка, которая будет выполнена стандартным интерпретатором команд.
В первых пяти полях значения можно перечислять через запятую:
Или через дефис:
Доступ пользователей к планированию задач регулируется в POSIX файлам cron.allow и cron.deny в которых перечисляются, соответственно, пользователи с доступом к crontab и пользователи без доступа к программе. Расположение этих файлов стандарт никак не регламентирует.
Запускаемым программам, согласно стандарту, должны передаваться по меньшей мере четыре переменные окружения:
- HOME — домашняя директория пользователя.
- LOGNAME — логин пользователя.
- PATH — путь, по которому можно найти стандартные утилиты системы.
- SHELL — путь к использованному командному интерпретатору.
Примечательно, что POSIX ничего не говорит о том, откуда берутся значения для этих переменных.
Хит продаж — Vixie cron 3.0pl1
Общий предок популярных вариантов cron — Vixie cron 3.0pl1, представленный в рассылке comp.sources.unix в 1992 году. Основные возможности этой версии мы и рассмотрим подробнее.
Vixie cron поставляется в двух программах (cron и crontab). Как обычно, демон отвечает за чтение и запуск задач из системной таблицы задач и таблиц задач отдельных пользователей, а утилита crontab — за редактирование пользовательских таблиц.
Таблица задач и файлы конфигурации
Таблица задач суперпользователя расположена в /etc/crontab. Синтаксис системной таблицы соответствует синтаксису Vixie cron с поправкой на то, что в ней шестой колонкой указывается имя пользователя, от лица которого запускается задача:
Таблицы задач обычных пользователей располагаются в /var/cron/tabs/username и используют общий синтаксис. При запуске утилиты crontab от имени пользователя редактируются именно эти файлы.
Управление списками пользователей, имеющих доступ к crontab, происходит в файлах /var/cron/allow и /var/cron/deny, куда достаточно внести имя пользователя отдельной строкой.
Расширенный синтаксис
По сравнению с POSIX crontab решение Пола Викси содержит несколько очень полезных модификаций в синтаксисе таблиц задач утилиты.
Стал доступен новый синтаксис таблиц: например, можно указывать дни недели или месяцы поимённо (Mon, Tue и так далее):
Можно указывать шаг, через который запускаются задачи:
Шаги и интервалы можно смешивать:
Поддерживаются интуитивные альтернативы обычному синтаксису (reboot, yearly, annually, monthly, weekly, daily, midnight, hourly):
Среда выполнения задач
Vixie cron позволяет менять окружение запускаемых приложений.
Переменные окружения USER, LOGNAME и HOME не просто предоставляются демоном, а берутся из файла passwd. Переменная PATH получает значение «/usr/bin:/bin», а SHELL — «/bin/sh». Значения всех переменных, кроме LOGNAME, можно изменить в таблицах пользователей.
Некоторые переменные окружения (прежде всего SHELL и HOME) используются самим cron для запуска задачи. Вот как может выглядеть использование bash вместо стандартного sh для запуска пользовательских задач:
В конечном итоге все определённые в таблице переменные окружения (используемые cron или необходимые процессу) будут переданы запущенной задаче.
Для редактирования файлов утилитой crontab используется редактор, указанный в переменной окружения VISUAL или EDITOR. Если в среде, где был запущен crontab, эти переменные не определены, то используется «/usr/ucb/vi» (ucb — это, вероятно, University of California, Berkeley).
cron в Debian и Ubuntu
Разработчики Debian и производных дистрибутивов выпустили сильно модифицированную версию версию Vixie cron 3.0pl1. Отличий в синтаксисе файлов-таблиц нет, для пользователей это тот же самый Vixie cron. Крупнейшие новые возможности: поддержка syslog, SELinux и PAM.
Из менее заметных, но осязаемых изменений — расположение конфигурационных файлов и таблиц задач.
Пользовательские таблицы в Debian располагаются в директории /var/spool/cron/crontabs, системная таблица всё там же — в /etc/crontab. Специфичные для пакетов Debian таблицы задач помещаются в /etc/cron.d, откуда демон cron их автоматически считывает. Управление доступом пользователей регулируется файлами /etc/cron.allow и /etc/cron.deny.
В качестве командной оболочки по умолчанию по-прежнему используется /bin/sh, в роли которого в Debian выступает небольшой POSIX-совместимый шелл dash, запущенный без чтения какой-либо конфигурации (в неинтерактивном режиме).
Сам cron в последних версиях Debian запускается через systemd, а конфигурацию запуска можно посмотреть в /lib/systemd/system/cron.service. Ничего особенного в конфигурации сервиса нет, любое более тонкое управление задачами возможно осуществить через переменные окружения, объявленные прямо в crontab каждого из пользователей.
cronie в RedHat, Fedora и CentOS
cronie — форк Vixie cron версии 4.1. Как и в Debian, синтаксис не менялся, но добавлена поддержка PAM и SELinux, работы в кластере, слежения за файлами при помощи inotify и других возможностей.
Конфигурация по умолчанию находится в обычных местах: системная таблица — в /etc/crontab, пакеты помещают свои таблицы в /etc/cron.d, пользовательские таблицы попадают в /var/spool/cron/crontabs.
Демон запускается под управлением systemd, конфигурация сервиса — /lib/systemd/system/crond.service.
В Red Hat-подобных дистрибутивах при запуске по умолчанию используется /bin/sh, в роли которого выступает стандартный bash. Надо заметить, что при запуске задач cron через /bin/sh командная оболочка bash запускается в POSIX-совместимом режиме и не читает никакой дополнительной конфигурации, работая в неинтерактивном режиме.
cronie в SLES и openSUSE
Немецкий дистрибутив SLES и его дериватив openSUSE используют всё тот же cronie. Демон здесь тоже запускается под systemd, конфигурация сервиса лежит в /usr/lib/systemd/system/cron.service. Конфигурация: /etc/crontab, /etc/cron.d, /var/spool/cron/tabs. В качестве /bin/sh выступает тот же самый bash, запущенный в POSIX-совместимом неинтерактивном режиме.
Устройство Vixie cron
Современные потомки cron по сравнению с Vixie cron не изменились радикально, но всё же обзавелись новыми возможностями, не требующимися для понимания принципов работы программы. Многие из этих расширений оформлены неаккуратно и путают код. Оригинальный же исходный код cron в исполнении Пола Викси читать одно удовольствие.
Поэтому разбор устройства cron я решил провести на примере общей для обеих ветвей развития cron программы — Vixie cron 3.0pl1. Примеры я упрощу, убрав усложняющие чтение ifdef-ы и опустив второстепенные детали.
Работу демона можно разделить на несколько этапов:
- Инициализация программы.
- Сбор и обновление списка задач для запуска.
- Работа главного цикла cron.
- Запуск задачи.
Разберём их по порядку.
Инициализация
При запуске после проверки аргументов процесса cron устанавливает обработчики сигналов SIGCHLD и SIGHUP. Первый вносит в лог запись о завершении работы дочернего процесса, второй — закрывает файловый дескриптор файла-лога:
Демон cron в системе всегда работает один, только в роли суперпользователя и из главной директории cron. Следующие вызовы создают файл-лок с PID-ом процесса-демона, убеждаются, что пользователь правильный и меняют текущую директорию на главную:
Выставляется путь по умолчанию, который будет использоваться при запуске процессов:
Дальше процесс «демонизируется»: создаёт дочернюю копию процесса вызовом fork и новую сессию в дочернем процессе (вызов setsid). В родительском процессе больше надобности нет — и он завершает работу:
Завершение родительского процесса высвобождает лок на файле-локе. Кроме того, требуется обновить PID в файле на дочерний. После этого заполняется база задач:
Дальше cron переходит к главному циклу работы. Но перед этим стоит взглянуть на загрузку списка задач.
Сбор и обновление списка задач
За загрузку списка задач отвечает функция load_database. Она проверяет главный системный crontab и директорию с пользовательскими файлами. Если файлы и директория не менялись, то список задач не перечитывается. В противном случае начинает формироваться новый список задач.
Загрузка системного файла со специальными именами файла и таблицы:
Загрузка пользовательских таблиц в цикле:
После чего старая база данных подменяется новой.
В примерах выше вызов функции process_crontab убеждается в существовании пользователя, соответствующего имени файла таблицы (если только это не суперпользователь), после чего вызывает load_user. Последняя уже читает сам файл построчно:
Здесь либо выставляется переменная окружения (строки вида VAR=value) функциями load_env / env_set, либо читается описание задачи (* * * * * /path/to/exec) функцией load_entry.
Сущность entry, которую возвращает load_entry, — это и есть наша задача, помещаемая в общий список задач. В самой функции проводится многословный разбор формата времени, нас же больше интересует формирование переменных окружения и параметров запуска задачи:
С актуальным списком задач и работает главный цикл.
Главный цикл
Оригинальный cron из Version 7 Unix работал совсем просто: в цикле перечитывал конфигурацию, запускал суперпользователем задачи текущей минуты и спал до начала следующей минуты. Этот простой подход на старых машинах требовал слишком много ресурсов.
В SysV была предложена альтернативная версия, в которой демон засыпал либо до ближайшей минуты, для которой определена задача, либо на 30 минут. Ресурсов на перечитывание конфигурации и проверку задач в таком режиме потреблялось меньше, но быстро обновлять список задач стало неудобно.
Vixie cron вернулся к проверке списков задач раз в минуту, благо к концу 80-х ресурсов на стандартных Unix-машинах стало значительно больше:
Непосредственно выполнением задач занимается функция cron_sleep, вызывающая функции job_runqueue (перебор и запуск задач) и do_command (запуск каждой отдельной задачи). Последнюю функцию стоит разобрать подробнее.
Запуск задачи
Функция do_command исполнена в хорошем Unix-стиле, то есть для асинхронного выполнения задачи она делает fork. Родительский процесс продолжает запуск задач, дочерний — занимается подготовкой процесса задачи:
В child_process довольно много логики: она принимает стандартные потоки вывода и ошибок на себя, чтобы потом переслать на почту (если в таблице задач указана переменная окружения MAILTO), и, наконец, ждёт завершения работы основного процесса задачи.
Процесс задачи формируется еще одним fork:
Вот, в общем-то, и весь cron. Какие-то интересные детали, например учёт удалённых пользователей, я опустил, но главное изложил.
Послесловие
Сron — на удивление простая и полезная программа, выполненная в лучших традициях мира Unix. Она не делает ничего лишнего, но свою работу выполняет замечательно на протяжении уже нескольких десятилетий. Ознакомление с кодом той версии, что поставляется с Ubuntu, заняло не больше часа, а удовольствия я получил массу! Надеюсь, я смог поделиться им с вами.
Не знаю, как вам, но мне немного грустно осознавать, что современное программирование с его склонностью к переусложнению и переабстрагированию уже давно не располагает к подобной простоте.
Существует множество современных альтернатив cron: systemd-timers позволяют организовать сложные системы с зависимостями, в fcron можно гибче регулировать потребление ресурсов задачами. Но лично мне всегда хватало простейших crontab.
Словом, любите Unix, используйте простые программы и не забывайте читать маны для вашей платформы!
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:
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
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:
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:
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:
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).
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.
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.
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.)
which is also equivalent to the more cumbersome
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:
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:
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:
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:
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:
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:
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:
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.
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 :
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.
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:
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 (;).
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.