crontab -e
を介してcronスケジューラーを定義すると、スケジューラーは正常に機能します。ただし、私の場合、ファイルを/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 Storageにバックアップしますが、Webコンソールで確認してもストレージは更新されません。
ここに足りないものはありますか? /etc/cron.hourly/
に配置されたスケジューラスクリプトが機能しないのはなぜですか?
echo test > /tmp/foobar.tmp
行をcronスクリプトに追加すると、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/
...で実行するとアクセスが拒否される理由を調査する必要がありますが、問題はcronではなくgcloud
にありました...コメントでのサポートに感謝します。
ログ出力を調査した後、ログファイルにgcloud
実行からの次のコンテンツが含まれていることが最終的にわかりました。
AccessDeniedException:403この操作を実行するにはOAuth2スコープが不十分です。
したがって、問題はcronではなくgcloud
にありました。
VM Cloud Storageへのアクセスを許可するには、次の手順を実行します。
VMインスタンスを停止します
VMを編集して、Cloud StorageをRead)からRead/Writeに変更します。
VMを再起動します
そして今、ついに予定通りに動作するようになりました...