Как отображать и просматривать список Cron Jobs с помощью Crontab

Команда crontab является основным интерфейсом для просмотра, редактирования и управления запланированными задачами в системе Unix cron. Чтобы вывести список всех cron-заданий для текущего авторизованного пользователя, выполните crontab -l в любом терминале. Для заданий root или системных заданий проверьте /etc/crontab, /etc/cron.d/ и /var/spool/cron/crontabs/ напрямую.

Cron является основой автоматизации задач в Linux и Unix-подобных системах. Независимо от того, выполняете ли вы ночные резервные копии баз данных в среде VPS Хостинга, ротацию логов на Выделенном сервере или автоматически обновляете SSL Сертификаты через Certbot, понимание того, как проверять и перечислять все запланированные задания на машине, является обязательным навыком системного администратора. Это руководство охватывает каждый уровень стека cron — пользовательские crontab, системные crontab, директории drop-in и спул — а также реальные подводные камни, с которыми сталкиваются даже опытные инженеры.

Что такое Crontab и как работает система Cron

Crontab (сокращение от «cron table») — это файл конфигурации для каждого пользователя, который указывает демону crond, какие команды и когда выполнять. Каждая учётная запись пользователя в системе — включая root — может иметь независимый crontab. Демон читает эти файлы при запуске и после любого редактирования, затем запускает задания в соответствии с их временными спецификациями.

Экосистема cron в современном дистрибутиве Linux состоит из нескольких отдельных уровней:

Пользовательские crontab — управляются через crontab -e и хранятся в /var/spool/cron/crontabs/ (Debian/Ubuntu) или /var/spool/cron/ (RHEL/CentOS)
Системный crontab — файл /etc/crontab, который включает дополнительное поле user для каждой записи
Директория drop-in — /etc/cron.d/, где пакеты устанавливают собственные определения заданий
Директории run-parts — /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/, которые содержат исполняемые скрипты, а не файлы в синтаксисе crontab
Anacron — дополнение к cron, которое обрабатывает задания на машинах, работающих не круглосуточно, читая из /etc/anacrontab

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

Синтаксис временных полей Crontab

Каждая запись crontab следует фиксированной пятипольной временной спецификации перед командой:

* * * * *  command_to_execute
| | | | |
| | | | +----- day of the week  (0–7, Sunday = 0 or 7)
| | | +------- month            (1–12)
| | +--------- day of the month (1–31)
| +----------- hour             (0–23)
+------------- minute           (0–59)

Специальные синтаксические сокращения, поддерживаемые большинством реализаций cron:

Сокращение	Эквивалент	Значение
`@reboot`	—	Запустить один раз при старте демона
`@yearly`	`0 0 1 1 *`	Один раз в год
`@monthly`	`0 0 1 * *`	Первый день каждого месяца
`@weekly`	`0 0 * * 0`	Каждое воскресенье в полночь
`@daily`	`0 0 * * *`	Каждый день в полночь
`@hourly`	`0 * * * *`	В начале каждого часа

Файлы /etc/crontab и /etc/cron.d/ добавляют шестое поле — имя пользователя, от имени которого выполняется команда — между временной спецификацией и самой командой.

Как вывести список Cron-заданий: все методы

1. Просмотр собственных пользовательских Cron-заданий

crontab -l

Это выводит crontab для пользователя, выполняющего команду. Если crontab ещё не существует, вы увидите либо пустой вывод, либо сообщение no crontab for <username> — оба варианта являются нормальными.

Пример вывода:

# m  h   dom mon dow  command
0    0   *   *   *    /home/deploy/backup.sh
30   2   *   *   7    /home/deploy/scripts/cleanup.sh
15   */4 *   *   *    /usr/local/bin/health-check.sh >> /var/log/health.log 2>&1

В этом примере:

backup.sh запускается каждый день в полночь
cleanup.sh запускается каждое воскресенье в 02:30
health-check.sh запускается каждые четыре часа начиная с 00:15, с перенаправлением stdout и stderr в файл журнала

Подводный камень: Перенаправление вывода (>>, 2>&1) часто опускается в записях crontab. Без него cron пытается отправить вывод по электронной почте локальному пользователю через sendmail. На серверах без агента передачи почты это молча отбрасывает весь вывод и делает отладку практически невозможной. Всегда перенаправляйте вывод или устанавливайте MAILTO="" в начале crontab.
2. Просмотр Cron-заданий другого пользователя
С правами sudo или root вы можете проверить crontab любого пользователя:
sudo crontab -l -u john
Замените john на имя целевого пользователя. Это функционально идентично чтению необработанного файла спула, но использует правильный механизм блокировки, поэтому всегда предпочтительнее прямого доступа к файлу.
3. Просмотр всех пользовательских Crontab одновременно
На многопользовательском сервере итерация по каждой учётной записи — единственный надёжный способ получить полную картину:
for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== Crontab for: $user ==="
    sudo crontab -l -u "$user" 2>/dev/null
done
Флаг 2>/dev/null подавляет сообщения «no crontab for» для пользователей, у которых нет crontab, сохраняя вывод чистым.
4. Просмотр общесистемного Crontab
cat /etc/crontab
Типичный вывод в системе на основе Debian:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m  h  dom mon dow  user     command
17  *  *   *   *    root     cd / && run-parts --report /etc/cron.hourly
25  6  *   *   *    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47  6  *   *   7    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52  6  1   *   *    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
Обратите внимание на защиту test -x /usr/sbin/anacron: если anacron установлен, эти вызовы run-parts пропускаются, и anacron берёт на себя ответственность за ежедневные, еженедельные и ежемесячные задания. Это распространённый источник путаницы, когда задания, по всей видимости, не выполняются по расписанию.
5. Просмотр заданий в /etc/cron.d/
ls -la /etc/cron.d/
Чтобы проверить содержимое каждого файла в директории за один проход:
grep -v '^#|^$' /etc/cron.d/*
Это убирает строки комментариев и пустые строки, показывая только активные определения заданий. Менеджеры пакетов часто помещают файлы сюда — распространённые примеры включают sysstat, переопределения logrotate и агенты мониторинга.
6. Прямая проверка директории спула Cron
ls -la /var/spool/cron/crontabs/
В RHEL, CentOS и Fedora путь — /var/spool/cron/ без поддиректории crontabs. Чтобы прочитать необработанный файл спула конкретного пользователя:
sudo cat /var/spool/cron/crontabs/username
Важно: Никогда не редактируйте файлы спула напрямую с помощью текстового редактора. Команда crontab -e использует блокировку файлов и проверяет синтаксис перед установкой нового файла. Прямое редактирование может повредить файл или оставить его в состоянии, при котором crond полностью его игнорирует.
7. Просмотр заданий Anacron
Если система использует anacron для надёжного планирования:
cat /etc/anacrontab
Записи Anacron используют другой синтаксис — период в днях, задержка в минутах, идентификатор задания и команда — а не стандартный пятипольный формат cron.
8. Проверка таймеров Systemd (современная альтернатива)
В дистрибутивах на основе systemd многие задачи, которые исторически управлялись cron, теперь обрабатываются таймерами systemd. Они не будут отображаться ни в одном списке crontab:
systemctl list-timers --all
Полный аудит сервера должен включать проверку как cron, так и таймеров systemd. Несоблюдение этого требования является одним из наиболее распространённых пробелов в проверках безопасности и соответствия требованиям.
Полный аудит Cron: команда для одного запуска
Для быстрого и всестороннего аудита всех запланированных задач в системе объедините все источники:
echo "=== /etc/crontab ===" && cat /etc/crontab
echo "=== /etc/cron.d/ ===" && ls /etc/cron.d/ && grep -rh '' /etc/cron.d/
echo "=== User crontabs ===" && for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null && echo "  ^ user: $u"; done
echo "=== Systemd timers ===" && systemctl list-timers --all --no-pager
Редактирование и управление Cron-заданиями
Чтобы открыть собственный crontab в редакторе по умолчанию системы ($VISUAL или $EDITOR, с откатом к vi):
crontab -e
Чтобы отредактировать crontab другого пользователя от имени root:
sudo crontab -e -u username
Чтобы удалить все cron-задания текущего пользователя (используйте с осторожностью — это необратимо без резервной копии):
crontab -r
Чтобы создать резервную копию crontab перед внесением изменений:
crontab -l > ~/crontab_backup_$(date +%F).txt
Всегда делайте резервную копию перед редактированием. В crontab -e нет встроенной функции отмены.
Cron vs. таймеры Systemd: сравнение функций




Функция
Cron
Таймеры Systemd




Формат конфигурации
Простой текст, пятипольный синтаксис
Файлы юнитов (.timer + .service)


Планирование для отдельного пользователя
Да, через пользовательские crontab
Да, через пользовательские экземпляры systemd


Обработка пропущенных заданий
Нет (задание пропускается, если система выключена)
Да, с Persistent=true


Журналирование
Syslog / почта
Journald (запрашивается с помощью journalctl)


Управление зависимостями
Нет
Полный граф зависимостей systemd


Случайная задержка
Не встроена (требует sleep $RANDOM)
RandomizedDelaySec=


Сложность
Низкая
Средняя


Доступность
Все Unix/Linux системы
Только Linux на основе Systemd




Для простой автоматизации на основе времени в любой Unix-системе — включая устаревшие среды и контейнеры — cron остаётся наиболее переносимым и операционно простым выбором. Таймеры systemd превосходят его, когда вам нужна упорядоченность зависимостей, надёжное выполнение пропущенных заданий или структурированный вывод журнала.
Основные команды для просмотра Crontab: краткий справочник




Цель
Команда




Список заданий текущего пользователя
crontab -l


Список заданий другого пользователя
sudo crontab -l -u username


Список заданий всех пользователей
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null; done


Просмотр системного crontab
cat /etc/crontab


Список заданий cron.d
ls /etc/cron.d/


Просмотр директории спула
ls /var/spool/cron/crontabs/


Просмотр заданий anacron
cat /etc/anacrontab


Список таймеров systemd
systemctl list-timers --all


Редактирование crontab текущего пользователя
crontab -e


Удаление crontab текущего пользователя
crontab -r




Реальные подводные камни и граничные случаи
Переменные окружения не наследуются. Cron запускает задания в минимальной среде оболочки. Переменные, такие как PATH, HOME и LANG, установленные в вашем .bashrc или .profile, недоступны. Всегда используйте абсолютные пути для команд и бинарных файлов или явно определяйте PATH в начале crontab.
Переменная MAILTO управляет маршрутизацией вывода. Установите MAILTO="" для отбрасывания вывода или MAILTO="admin@example.com" для его перенаправления на конкретный адрес. Без настроенного MTA необработанный вывод вызывает молчаливые сбои.
Права доступа к скриптам имеют значение. Скрипт, который нормально работает в интерактивном режиме, может завершиться с ошибкой под cron, если он не является исполняемым (chmod +x) или если он обращается к файлам, которые пользователь cron не может прочитать.
Перекрывающееся выполнение заданий. Если задание выполняется дольше своего интервала, несколько экземпляров будут запущены одновременно. Используйте файл блокировки или flock для предотвращения этого:
0 * * * * /usr/bin/flock -n /tmp/myjob.lock /home/user/long-running-job.sh
Учёт часового пояса. Cron использует системный часовой пояс по умолчанию. На серверах с UTC, установленным в качестве системных часов — что является стандартной практикой на VPS Хостинге и Выделенных серверах — убедитесь, что ваше запланированное время учитывает смещение. Некоторые реализации cron поддерживают переменную CRON_TZ для каждого crontab.
Проверка синтаксиса Crontab. Перед развёртыванием новой записи crontab в производственной среде проверьте выражение с помощью такого инструмента, как crontab.guru, чтобы убедиться, что расписание соответствует вашим намерениям.
Журналирование и отладка Cron-заданий
По умолчанию cron записывает выполнение заданий в syslog. Чтобы просмотреть последнюю активность cron:
grep CRON /var/log/syslog | tail -50
В системах на основе systemd:
journalctl -u cron --since "1 hour ago"
Если задание не выполняется, проверьте:

Демон cron активен: systemctl status cron (или crond в системах на основе RHEL)
Скрипт является исполняемым и путь указан правильно
Временные поля синтаксически корректны
Вывод не отбрасывается молча — временно добавьте >> /tmp/job.log 2>&1

Пользователь, запускающий задание, имеет разрешение на выполнение команды

При управлении сложными стеками автоматизации на VPS с cPanel, cPanel предоставляет графический интерфейс Cron Jobs в разделе Advanced, который записывает напрямую в crontab пользователя. Задания, добавленные через cPanel, полностью видны с помощью crontab -l и ведут себя идентично записям, добавленным вручную.

Матрица решений: какой уровень Cron использовать

Сценарий использования	Рекомендуемый уровень
Личная автоматизация для одного пользователя	Пользовательский crontab (`crontab -e`)
Задачи обслуживания системы (резервное копирование, ротация логов)	`/etc/cron.d/` или `/etc/crontab`
Скрипты, которые должны выполняться даже после пропущенного расписания	Anacron (`/etc/anacrontab`)
Задачи со сложными зависимостями или упорядочением сервисов	Таймеры Systemd
Задания уровня приложения, развёртываемые с пакетом	`/etc/cron.d/<package-name>`
Контейнерные среды	Supervisor + cron или Kubernetes CronJob

Практический контрольный список ключевых выводов

Запустите crontab -l для аудита собственных заданий; используйте шаблон цикла for для аудита каждого пользователя на многопользовательском сервере.
Всегда проверяйте /etc/crontab, /etc/cron.d/ и systemctl list-timers --all — crontab -l в одиночку даёт неполную картину.
Используйте абсолютные пути для всех команд и бинарных файлов внутри записей crontab.
Установите MAILTO="" или явно перенаправляйте вывод для предотвращения молчаливых сбоев на серверах без MTA.
Создавайте резервную копию crontab с помощью crontab -l > backup.txt перед любым сеансом редактирования.
Используйте flock для предотвращения одновременного выполнения длительных заданий.
В системах systemd проверяйте journalctl -u cron, а не полагайтесь исключительно на /var/log/syslog.
Проверяйте новые временные выражения с помощью онлайн-тестера выражений cron перед развёртыванием в производственной среде.
Учитывайте UTC и местный часовой пояс на облачных экземплярах и экземплярах VPS Хостинга.
Для серверов Email Хостинга или любой инфраструктуры, где задания являются критически важными, внедрите внешний мониторинг (например, пинги healthcheck) для обнаружения молчаливых сбоев cron.

FAQ

Как вывести список всех cron-заданий для каждого пользователя на Linux-сервере?

Выполните итерацию по /etc/passwd и вызовите sudo crontab -l -u <user> для каждой учётной записи, подавляя ошибки «no crontab» с помощью 2>/dev/null. Дополнительно проверьте /etc/crontab, /etc/cron.d/ и выполните systemctl list-timers --all для захвата системных заданий и заданий, управляемых systemd.

Почему crontab -l ничего не показывает, хотя задания выполняются?

Задания, скорее всего, определены в /etc/crontab, файле внутри /etc/cron.d/ или как таймеры systemd — ни одно из них не видно через crontab -l. Эта команда показывает только личный crontab вызывающего пользователя, хранящийся в директории спула.

В чём разница между /etc/crontab и /etc/cron.d/?

Оба используют одинаковый шестипольный синтаксис (включая поле имени пользователя) и читаются системным демоном cron. /etc/crontab — это единый монолитный файл, предназначенный для ручного системного администрирования. /etc/cron.d/ — это директория drop-in, куда отдельные пакеты или сервисы устанавливают собственные файлы заданий, сохраняя их изолированными и упрощая управление или независимое удаление.

Как предотвратить запуск нескольких перекрывающихся экземпляров cron-задания?

Оберните команду с помощью flock -n /tmp/lockfile.lock для получения неблокирующей эксклюзивной блокировки. Если предыдущий экземпляр всё ещё выполняется, новый вызов немедленно завершается без выполнения команды, предотвращая конкуренцию за ресурсы и повреждение данных.

Где хранятся журналы cron-заданий и как отладить задание, которое не выполняется?

В большинстве систем cron записывает в /var/log/syslog (фильтруйте с помощью grep CRON) или через journald (journalctl -u cron). Для отладки временно добавьте >> /tmp/debug.log 2>&1 к команде задания для захвата всего вывода, убедитесь, что скрипт является исполняемым, подтвердите, что демон запущен с помощью systemctl status cron, и проверьте временное выражение независимо.