cronを設定したはいいけれども、初歩的なミスで動かなかったのを動けるようにしたって話。
そのうえで、知ったこととミスの考察。
やりたかったこと
WSL2で20分おきにシェルスクリプトを動かしたかった
環境
$ cat /proc/version
Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Mar 29 23:14:13 UTC 2024
↑要約：WSL2のUbuntu
cronの設定
$ clontab -l
3/20 * * * * /usr/bin/sh script.sh
script.sh内では、複数のPythonを実行している。
awsやcloudflare r2にあれこれするという処理をしていて、KEYの類は環境変数に設定してある。
普通に実行する分には問題なく動き、cronに設定したのがまったく持って動かない。
動かなかった理由と解決方法
動かなかった理由
cron実行時は、ユーザーと違う環境変数であるというのを知っていたのにもかかわらず、設定していなかったため。
解決方法
具体的に行った処理
$ sudo cp /etc/environment /etc/environment.2024-10-09
$ env | sudo tee -a /etc/environment
1行目で、バックアップとして既存の/etc/environmentをコピー
2行目で、ローカルの環境変数を/etc/environmentに追記
解決ついでにわかったこと
cronの書き方
複数のコマンドを処理させるとき、どちらの書き方でも動いた
例：/home/user/dir/に移動してからcommandを実行
* * * * * cd /home/user/dir/ && command
* * * * * cd /home/user/dir/ ; command
曜日指定は数字以外もOK
例：月曜日から金曜日までの間はcommandを実行
* * * * mon-fri command
考察（という名目での感想）
この解決に至るまで、累積作業時間として小一時間（３日間、ちょっと試しては動かないってのを繰り返したけど）ぐらいcronをいじっていました。
こんな見落としするんだなあ、と思ったポイントは、知識で知っていても実際に手を動かしているとそれが対処法として結びつかないということでした。
流れとしては、
- cronが動かん
-
script.shがなんか渋ってる - なんでだ？
という段階で、環境変数というのに気づかず、cronの設定ミスかと見直しをしてました。
その次の流れとして、
-
script.shが渋ってるのはなんぞや？ - とりあえず、cronの記述内に
script.shの処理をTEXTに書き出す追記をしよう - pythonが環境変数の値がなくってコケてのか！
と、解決策に結びつきました。
cronでの実行時は、一般ユーザーと環境変数が異なるってのは知識で知っていたのですが、完全に脳内で別の箱に入っていてつながってませんでした。
技術書や技術記事で知っていることであっても、頭の片隅においておくじゃなくって実際に動かすというところで自分の手の中に落とさないとだめだなあ、なんて思いました。