Если я определяю свой планировщик крона через 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
Снова, сценарий хорошо работал, если я вручную выполнил его, таким образом, переменные среды установлены на правильные значения...
Я наконец нашел это после получения файла журнала выпущенным gsutil
команда, это имеет следующее содержание:
AccessDeniedException: 403 Недостаточных OAuth2 определяют объем для выполнения этой операции.
Я все еще должен заняться расследованиями, почему доступ запрещен, если выполнено в /etc/cron.hourly/
... Но проблема шла gcloud
, не крон... Спасибо за поддержку в комментариях.
После исследования вывода журнала я наконец нашел, что файл журнала включал следующее содержание, которое является от gcloud
выполнение:
AccessDeniedException: 403 Недостаточных OAuth2 определяют объем для выполнения этой операции.
, Таким образом, проблема была на gcloud
, не крон.
, Чтобы предоставить доступу VM Облачное хранилище, возьмите следующие шаги:
Остановка Ваш экземпляр VM
Редактирование Ваш VM для изменения Облачного хранилища от Read к Чтение-запись .
Перезапуск Ваш VM
И теперь я наконец получил его работающий, как запланировано...
Вы не предоставили достаточно информации о сценарии для понимания то, что это, как предполагается, делает, ни почему это могло бы перестать работать в задании крона - существует пара общих причин.
Однако заголовок Вашего вопроса и первый абзац (о пользователе и корне 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.