Діагностика cron: вручну працює, за розкладом — ні

Звіт сайту формується, коли адміністратор запускає скрипт у терміналі, але запланованого результату немає. Перша реакція — змінити години або надати процесу більше прав. Проте cron може запускати правильну команду в іншому середовищі. Діагностика cron починається з розділення двох ситуацій: задача взагалі не стартує або стартує, але працює не так, як ручний запуск.

Нижче — навчальний сценарій для Linux із традиційним cron і оболонкою /bin/sh. Він не описує реальний клієнтський збій і не встановлює нового розкладу. Потрібні термінал, текстовий редактор та власний тестовий каталог. Python у прикладі лише шукається як програма; виконання Python-коду не потрібне. Не запускайте справжнє надсилання листів, списання коштів чи синхронізацію повторно заради перевірки: такі дії можуть створити дублікати.

З’ясуйте, що саме планувальник запускає

Візьміть точний текст команди з погодженої конфігурації або панелі хостингу. Зафіксуйте власника задачі, часовий пояс сервера та очікуваний момент запуску. Не переносіть рядок між користувацьким crontab і системним файлом механічно: їхній формат може відрізнятися. Також перевірте, чи задача керується cron, панеллю або іншим планувальником; назва «cron» у повідомленні колеги цього не доводить.

В довідці Debian для crontab описано користувача виконання, оболонку та особливості рядка команди. Зокрема, знак відсотка має спеціальне значення в такій реалізації. Якщо команда містить форматування дати з відсотками, перевірте саме правила вашого планувальника. Не копіюйте приклад для іншої системи навмання. Для контейнерів і systemd timers наведений нижче тест середовища залишається підказкою, але не інструкцією налаштування їхнього розкладу.

Відокремте повідомлення «планувальник запустив команду» від підтвердження результату. Наявність запису про старт ще не доводить, що створено потрібний файл. Водночас відсутність очікуваного файла не доводить відсутність запуску. Попросіть адміністратора показати доступний запис про виконання та статус завершення без секретів. Поки цих фактів немає, причина залишається гіпотезою, а не встановленою несправністю cron.

Побачте різницю без доступу до продуктивних даних

Створіть у власному тестовому каталозі check-context.sh із наведеним вмістом. Поруч створіть порожній input.txt через редактор. Обидві назви умовні. Скрипт лише показує поточний каталог, шукає python3 і перевіряє доступність тестового файла; він не читає його вміст і не змінює налаштування. Запуск через /bin/sh не вимагає надання файлу права виконання.

#!/bin/sh
printf 'working_directory: '
pwd
printf 'python_lookup: '
command -v python3 || printf 'not found\n'
if [ -r ./input.txt ]; then
    printf 'relative_input: readable\n'
else
    printf 'relative_input: missing or unreadable\n'
fi

Виконайте дві команди нижче з цього самого каталогу. Перша використовує поточне середовище термінала. Друга запускає діагностику з очищеним середовищем і явно заданим коротким PATH. Це наближення для перевірки залежностей, а не точна копія cron. PATH тут — параметр лише дочірнього процесу; не змінюйте заради вправи глобальні налаштування оболонки чи системи.

/bin/sh ./check-context.sh
env -i PATH=/usr/bin:/bin /bin/sh ./check-context.sh

Порівняйте три рядки результату. Якщо python3 знаходиться тільки під час першого запуску, ручна сесія має додатковий шлях до програми. Якщо обидва запуски знаходять однаковий інтерпретатор, це теж корисний результат: у цій перевірці різниці немає. Не оголошуйте PATH причиною без такого підтвердження. Призначення env -i описане в документації GNU env; воно не означає автоматичного відтворення всіх умов фонового процесу.

Перевірте каталог окремо від середовища

Тепер відкрийте термінал в іншому власному каталозі та запустіть скрипт за абсолютним шляхом. Нижче умовний шлях /srv/cron-demo: замініть його реальним шляхом до вашої тестової папки. Не створюйте системний каталог лише для відповідності прикладу. Наявність shell і право читання скрипту залишаються необхідними; адміністративні права не потрібні.

/bin/sh /srv/cron-demo/check-context.sh

Очікуйте, що working_directory показуватиме каталог, з якого ви запустили оболонку. Файл input.txt поруч зі скриптом може при цьому визначитися як недоступний, адже ./input.txt відноситься до поточного каталогу процесу, не до розташування скрипту. Це пояснює, чому виправлення одного абсолютного шляху до програми не завжди ремонтує доступ до даних. Перевірте обидві залежності окремо, перш ніж міняти розклад.

Для справжньої задачі погодьте робочий каталог або використайте явні шляхи до потрібних файлів. Перевіряйте фактичний інтерпретатор і його залежності, а не тільки назву команди. Якщо скрипт потребує змінних застосунку, передавайте їх через передбачений проєктом захищений механізм. Не друкуйте весь env у журнал: там можуть бути токени та паролі. Не вставляйте секрети безпосередньо в рядок розкладу чи скриншот для підтримки.

Зробіть виправлення перевірюваним і оборотним

Права доступу перевіряйте від імені погодженого користувача задачі разом з адміністратором. Читання скрипту, проходження каталогів і запис результату — різні дозволи. Не усувайте помилку через chmod 777 або запуск від root без обґрунтованої потреби. Якщо процес не може записати звіт, спочатку підтвердьте цільовий каталог і власника. Для безпечного доступу доречний матеріал про налаштування SSH.

Перед зміною продуктивної команди збережіть попередню конфігурацію та протестуйте конкретне виправлення на копії. Якщо додаєте журнал, використайте окремий захищений файл, перевірте місце на диску та строк зберігання. Запис журналу сам може не відбутися через права. Фіксуйте початок, завершення та безпечний ідентифікатор операції; відсутність тексту помилки не вважайте успіхом. За потреби відкату поверніть саме попередню команду, не вимикаючи всі задачі сервера.

Висновок: спочатку підтвердьте старт, потім відтворіть каталог і середовище, а вже тоді виправляйте знайдену залежність. Після зміни перевірте наступний погоджений запуск і фактичний результат, а не лише зелений статус панелі. Якщо ручне та фонове виконання продовжують відрізнятися, AriZone може допомогти зіставити умови й перевірити точкове виправлення без ризикованих повторних операцій.