2023年7月から Windows Subsystem for Linux （WSL）の crond をWindows タスクスケジューラーから起動できなくなっていることに今頃気づきました。
Windows10には、標準でLinux実行環境モジュールが組み込まれていて、Windows PC上でLinuxプログラムを動かすことが出来るのですが、残念ながら、まだ細かいところが不十分です。その一つが crond。
例えば、Windows タスクスケジューラーに相当する cron 機能がLinuxに存在していますが、WSL起動時にデーモンを自動起動できない！これはWSLの仕様のようです。
私の場合、ラジオのリアルタイム録音をWSL上で行っており、自動録音なので当然番組開始時刻と連動させたいわけです。しかし、crontab に録音開始時刻と録音スクリプトを登録しても、cronデーモンが動かないとスクリプトは動かない。
cronデーモンを動かすためには、linuxコマンドプロンプトから「service cron start」を実行すればいいだけで、手動でPCを再起動する場合は実現可能ですが、Windows Updateで、PCが自動起動されてしまった場合は、cron デーモンが止まっていることにしばらく気づかないことが多々あります。これでは困るので、2023年6月までは Windows タスクスケジューラーから、WSL側 crond を起動させてきました。そして、この仕組みが突然動かなくなっていることに気づきました。
WSLのcronで行っていたのは、ラジコのバックアップリアルタイム録音。バックアップなので重要性は低かったものの、稀に Radikoタイムフリーのデータが壊れていることがあって、そういう時にリアルタイム録音のデータが必要になります。気づくのが相当遅かったわけですが、幸いなことに停止期間は、タイムフリーで間に合っていました。
今わかっていることは、OSが起動した後、タスクスケジューラーから手動でタスクをスタートさせれば、タスクマネージャからcron タスクが起動していることを確認できるので、バッチファイル自体は動くってこと。
タスクスケジューラーから確認できる、「履歴」タブ内の情報が、これまた役に立たない。
「操作 “C:\WINDOWS\SYSTEM32\cmd.exe” を正常に完了しました。リターン コード: 4294967295」
「操作 “C:\WINDOWS\SYSTEM32\cmd.exe” を正常に完了しました。リターン コード: 2147942401」など。
数値の部分は、10進表示か16進表示なので、0xFFFFFFFF と 0x1 の場合もありかも。
問題切り分けのためにいろいろやってみました。
- wsl コマンドを呼ぶバッチファイルを、cmd.exe /C の引数にしてみた。
- cmd.exe を C:\Windows\… からのフルパスで与えてみた。
- 起動時に一度だけ実行されるコマンドとしてタスクスケジューラーに登録していますが、これをログイン時に実行するタスクにしてみた。
結果は全部だめ。WSL cron は自動起動しないけど、タスクスケジューラーから手動で実行すれば起動する。
この結果から、
- タスクスケジューラーに登録するバッチファイルの書式が変わったわけではなさそう。
- Windows Updateでタスク起動に必要な権限が強化されたのか、より厳密にファイルとコマンドのパーミッションをチェックするようになったか？
- WSLに必要なWindows コマンドの場所が変わった？（可能性は低い）
- ログイン後に設定されるPATHに含まれる情報が有効になるタイミングが変わった？
のようなことが原因として考えられますが、まだ、解決に至らず。2が原因のような気がしています。
3日間いろいろ試したものの、タスクスケジューラーからWSL cron を起動できない。エラー解析できない原因は、タスクスケジューラーの履歴から読み取れるエラーコードが何を意味しているか正確にわからないこと。チラッとでもエラーメッセージが見えたり、経過を保存できれば対処のしようもあるのですが、HDDモデルのPCを何度も再起動を繰り返すのは疲れる。設定をちょっと修正しては、5～10分待ちなので回数試せない。
タスクスケジューラーによるcron起動は諦めて、スタートアップフォルダーにバッチファイルのショートカットを置くことで回避することにしました。（このやり方好きじゃないんですが、やむを得ない。）
バッチファイル自体はダブルクリックで WSL cron が起動するわけだから、コマンド内容は問題ない。
再起動後、指定アカウントで自動ログインし、スタートアップフォルダーに置いたショートカットでcronが起動させるという回避策。スタートアップフォルダーに置く方法の欠点は、ログオフ→ログイン を繰り返すと、WSL cron が重複発行されてしまうこと。一度ログインすると、基本的にはログオフする必要がないPCなので、不具合は起きないと思うのですが。
テストしたところ、無事にcron が起動しました。いつまでも原因調査に時間を掛けていられないので、この方法で妥協することにしました。