Як відобразити та переглянути список Cron Jobs за допомогою Crontab

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

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

Що таке 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 на ім’я цільового користувача. Це функціонально ідентично читанню необробленого файлу spool, але використовує належний механізм блокування, тому завжди є кращим варіантом порівняно з прямим доступом до файлу.
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. Безпосередня перевірка директорії spool cron
ls -la /var/spool/cron/crontabs/
У RHEL, CentOS та Fedora шлях — /var/spool/cron/ без піддиректорії crontabs. Щоб прочитати необроблений файл spool конкретного користувача:
sudo cat /var/spool/cron/crontabs/username
Важливо: Ніколи не редагуйте файли spool безпосередньо за допомогою текстового редактора. Команда 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 проти таймерів 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/


Переглянути директорію spool
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 Hosting та Виділених серверах — переконайтеся, що ваші заплановані часи враховують зміщення. Деякі реалізації 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 Hosting.
• Для серверів Email Hosting або будь-якої інфраструктури, де завдання є критично важливими, впроваджуйте зовнішній моніторинг (наприклад, 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 користувача, що викликає команду, збережений у директорії spool.

У чому різниця між /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, та незалежно перевірте часовий вираз.