Как отображать и просматривать список 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:

Файлы /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 -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, и проверьте временное выражение независимо.