Как я могу заставить Cron запустить работу прямо сейчас, для тестирования / отладки? без изменения графика!

135

У меня есть задание cron, которое планируется запускать каждый день, кроме изменения расписания. Есть ли другой способ выполнить тестовый прогон команды прямо сейчас, чтобы проверить, работает ли она как задумано?

cron debugging

— Али
источник

Я не понимаю ваш вопрос? Почему бы просто не запустить команду?

— Favadi

21

Я знаю, что команда работает, когда вводит ее в shell (моя оболочка), но я хочу знать, работает ли она, когда cronзапускает ее, на нее могут влиять ENV или специфичные для оболочки вещи ( ~расширение) или вещи с правами собственности и разрешениями или ...

— Али

2

Так почему бы не создать новое задание cron, запускаемое каждую минуту одной и той же командой?

— фавади

13

Это именно то, что я в итоге сделал, но мне было интересно, есть ли способ сказать cron, что вы хотите выполнить тестовый задание № 7! Конечно, у других была эта проблема / просьба / желание раньше!

— Али

4

Очень поздно на сцену через Google, но в ответе Фавади было все не так. Было ясно, что он хотел протестировать его из cron и без редактирования crontab специально для этого. Немного хуже, чем кто-то, кто говорит вам, что вы хотите, это неправильно, если они не пытались понять вариант использования.

— HörmannHH

32

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

— Ульрих Дангел
источник

57

Вы можете принудительно запустить crontab с помощью следующей команды:

run-parts /etc/cron.daily

— Вадим Слуцкий
источник

9

... исходя из предположения, что задание OP cron (заданное 3 года назад) находится в cron.daily, а не в отдельном crontab.

— Джефф Шаллер

18

Однако это не полностью имитирует среду пользователя cron, поэтому весьма вероятно, что у вас все еще будут ошибки, потому что как только вы запустите свой скрипт как реальное задание cron, ваш PATH и другие envvars могут отличаться от пользователя, которым вы делали run-parts /etc/cron.daily. Я борюсь с этой ошибкой прямо сейчас, так как мой скрипт работает нормально, run-partsно не работает, когда фактически запускается от имени пользователя cron.

— ArtHare

42

Вы можете смоделировать пользовательскую среду cron, как описано в разделе «Запуск задания cron вручную и немедленно» . Это позволит вам проверить работу задания, когда оно будет запущено от имени пользователя cron.

Выдержка из ссылки:

Шаг 1 : Я временно поместил эту строку в crontab пользователя:

* * * * *   /usr/bin/env > /home/username/tmp/cron-env

затем вынул его, как только файл был написан.

Шаг 2 : Сделал себе маленький bash-скрипт run-as-cron, содержащий:

#!/bin/bash
/usr/bin/env -i $(cat /home/username/tmp/cron-env) "$@"

Итак, как пользователь, я смог

run-as-cron /the/problematic/script --with arguments --and parameters

— Майкл Бартон
источник

Полезный трюк. Конечно, это не поможет, если в вашей команде есть знак процента.

— basic6

0

Я нашел решение, которое, кажется, немного лучше для моих целей (команды показаны для CentOS / RHEL-подобных, но должны быть адаптированы в любом месте).

Это требует libfaketime- вы можете собрать его самостоятельно из исходного кода по адресу https://github.com/wolfcw/libfaketime или просто использовать один из множества пакетов из https://pkgs.org/download/libfaketime .

Остановить службу crond - service crond stop
Выясните, когда должен работать ваш сервис - https://crontab.guru очень полезен для этого.
Запустите crond в режиме переднего плана с помощью faketimeинструмента libfaketime (он позволяет вам подделать системный вызов для поиска времени для любых дочерних процессов).
1. Я бы не стал запускать это на производственном сервере
2. faketime '2019-10-17 07:59:50' /usr/sbin/crond -n -x test,sch

[root@user-crontesting-dvc-01 ~]# faketime '2019-10-17 07:59:50' /usr/sbin/crond -n -x sch
debug flags enabled: sch
[4841] cron started
log_it: (CRON 4841) INFO (Syslog will be used instead of sendmail.)
log_it: (CRON 4841) INFO (RANDOM_DELAY will be scaled with factor 34% if used.)
log_it: (CRON 4841) INFO (running with inotify support)
[4841] GMToff=0
log_it: (CRON 4841) INFO (@reboot jobs will be run at computer's startup.)
[4841] Target time=1571299200, sec-to-wait=11
user [root:0:0:...] cmd="/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1"
[4841] Target time=1571299260, sec-to-wait=60
log_it: (root 4844) CMD (/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1)
log_it: (root 4843) CMDOUT (/bin/bash: -c: line 0: syntax error near unexpected token `&')
log_it: (root 4843) CMDOUT (/bin/bash: -c: line 0: `/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1')

— javanix
источник