Задание крона не работает, когда оно вставляется в '/etc/cron.hourly /' но работа при определении в 'crontab-e'

Если я определяю свой планировщик крона через crontab -e, планировщик работает правильно. Однако вставление файла /etc/cron.hourly/ не работает в моем случае.

Выполнение run-parts --test /etc/cron.hourly произведите сценарий. Кроме того, название сценария my_sql_backup и не имеет расширения файла.

Сценарий root:root с 777 разрешениями.

cron.hourly планировщик, кажется, работает, поскольку это - вывод grep CRON /var/log/syslog:

Mar  1 11:17:01 my-instance CRON[12919]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Кроме того, если я вручную выполнил команду, планировщик работал точно так же, как это должно:

sudo bash -c "cd / && run-parts --report /etc/cron.hourly"

Однако это, кажется, не работает на самом деле. Сценарий вернулся база данных MySQL к устройству хранения данных Google Cloud, но устройство хранения данных не обновляется, когда я проверяю его через веб-Консоль.

Есть ли что-нибудь, что я пропускаю здесь? Почему мой планировщик пишет сценарий, который был вставлен /etc/cron.hourly/ не работают?


ОБНОВЛЕНИЕ

Добавив echo test > /tmp/foobar.tmp строка к моему сценарию крона, я нашел, что tmp файл там. На самом деле я нашел свой собственный tmp файл выпущенным сценарием.

Содержание сценария следующее. Таким образом, возможно, проблема произошла в выполнении gsutil команда?

# define environment variables here
sudo sh -c "mysqldump -u$MYSQL_USER -p$MYSQL_PASS $MYSQL_DBNAME --single-transaction | gzip -9 > $MYSQL_TEMPPATH" >/dev/null 2>&1
gsutil cp $MYSQL_TEMPPATH gs://$GS_BUCKET_NAME/$MYSQL_S3_DESTPATH >/dev/null 2>&1

Снова, сценарий хорошо работал, если я вручную выполнил его, таким образом, переменные среды установлены на правильные значения...


ОБНОВЛЕНИЕ 2

Я наконец нашел это после получения файла журнала выпущенным gsutil команда, это имеет следующее содержание:

AccessDeniedException: 403 Недостаточных OAuth2 определяют объем для выполнения этой операции.

Я все еще должен заняться расследованиями, почему доступ запрещен, если выполнено в /etc/cron.hourly/... Но проблема шла gcloud, не крон... Спасибо за поддержку в комментариях.

1
задан 3 March 2017 в 08:31

2 ответа

После исследования вывода журнала я наконец нашел, что файл журнала включал следующее содержание, которое является от gcloud выполнение:

AccessDeniedException: 403 Недостаточных OAuth2 определяют объем для выполнения этой операции.

, Таким образом, проблема была на gcloud, не крон.

Поэтому, как избежать ошибки доступа запрещен на gcloud?

, Чтобы предоставить доступу VM Облачное хранилище, возьмите следующие шаги:

  1. Остановка Ваш экземпляр VM

  2. Редактирование Ваш VM для изменения Облачного хранилища от Read к Чтение-запись .

  3. Перезапуск Ваш VM

И теперь я наконец получил его работающий, как запланировано...

источник: https://stackoverflow.com/a/41604071/2360798

1
ответ дан 8 December 2019 в 06:22

Вы не предоставили достаточно информации о сценарии для понимания то, что это, как предполагается, делает, ни почему это могло бы перестать работать в задании крона - существует пара общих причин.

Однако заголовок Вашего вопроса и первый абзац (о пользователе и корне crontabs) кажутся достаточно четкими, поэтому давайте ответим что:

Пользователь crontabs и корень crontabs имеют немного отличающиеся форматы и не являются взаимозаменяемыми.

Пример:

1 1 * * * root /bin/foo   // root crontab in /etc/cron*
1 1 * * * /bin/foo        // user crontab in /var/spool (see it using the 'crontab' command

Посмотрите различие? Корень crontab имеет дополнительное поле для определения пользователя. Пользователь не должен быть корнем...., хотя на практике это обычно - корень.

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

-1
ответ дан 8 December 2019 в 06:22

Другие вопросы по тегам:

Похожие вопросы: