Блог

my_cron -файл работает, когда он создается непосредственно в /etc/cron.d/ :

 sudo nano /etc/cron.d/my_cron

# Add content:
* * * * * username /path/to/python /path/to/file 2>/path/to/log
  

Но это не работает, когда я копирую / перемещаю его в каталог:

 sudo cp ./my_cron /etc/cron.d/my_cron
  

ls -l /etc/cron.d оба раза выводит одинаковые разрешения : -rw-r--r-- . Файлы принадлежат root .

Единственная причина, которую я мог себе представить на данный момент, это то, что я должен обновить / активировать что-то после копирования, что происходит автоматически при создании.

Протестировано на Ubuntu и Raspbian.

Есть идеи? Спасибо!

Старые cron демоны проверяли /etc/cron.d обновленное содержимое только тогда, когда видели, что метка времени последнего изменения этого каталога или /etc/crontab файла изменилась с момента последнего cron сканирования. Последние cron демоны также проверяют временные метки отдельных файлов, /etc/cron.d но, возможно, здесь вы имеете дело со старым.

Если у вас есть старый cron , то если вы скопировали совершенно новый файл, /etc/cron.d то временная метка каталога должна измениться и cron должен появиться новый файл. Однако, если вы cp просто перезаписывали существующий файл, это не изменило бы временную метку каталога и cron не получило бы новое содержимое файла.

Редактирование файла на месте в /etc/cron.d не обязательно обновит временную метку каталога, но некоторые редакторы (конечно vi , если вы не настроили его иначе) создадут временные рабочие файлы и, возможно, файл резервной копии в каталоге, в котором находится редактируемый файл. Создание и удаление этих других файлов приведет к обновлению временной метки каталога, что приведет cron к вступлению отредактированного файла в силу. Это может объяснить, почему редактирование ведет себя для вас иначе, чем cp редактирование.

Чтобы принудительно обновить временную метку, вы можете сделать что sudo touch /etc/crontab -то вроде или создать и немедленно удалить исходный файл (или каталог) /etc/cron.d после cp rm того, как вы отредактировали или отредактировали там файл. Очевидно touch , что это проще. Если вы хотите перейти по маршруту create delete, то mktemp для этого было бы хорошим инструментом, чтобы избежать блокировки чужого законного файла.

Если бы вы были действительно параноиком, вы бы подождали хотя бы секунду между внесением изменений в файл, а затем делали все, что захотите, чтобы принудительно обновить временную метку. Это должно избежать ситуации, когда cron повторное сканирование, обновления вашего файла и ваше touch или scratch create delete могут произойти в пределах детализации метки времени.

Если вы хотите посмотреть, что вы cron на самом деле делаете, вы можете sudo strace -p <pid-of-cron> . В основном он спит по минуте за раз, но вы будете видеть stat некоторые файлы и каталоги (включая /etc/crontab и /etc/cron.d ) каждый раз, когда он просыпается. И, конечно, если он решит, что ему нужно выполнить задание, вы тоже увидите это действие.