Zima Cronは、汎用Dockerコンテナとして追加されたものではなく、ZimaOS向けに直接公開された数少ないスケジューリングツールの1つです。IceWhaleの2026年1月のチュートリアルでは、次の方法でインストールする手順が示されています。 zpkgインターバルベースまたはcron式のタスクを作成し、ログで実行を確認して、スクリプト、バックアップ、定期メンテナンスに使用します。
ソーススレッドには、短縮版の本記事で以前は大幅に圧縮しすぎていた重要な別の話も含まれています。再起動後の永続性はシステムによって一貫していませんでした。一部のZimaOS 1.5.3および1.5.4のユーザーは、スケジュール済みタスクをすべて失ったり、タスクが見つからないことに気付いたりしました。 zima-cron.service 再起動後に非アクティブになる一方、クリーンなテスト環境ではタスクが再起動後も保持されました。したがって、正しい捉え方は単に「インストールして放置する」ことではなく、「バージョンによって永続性に注意が必要な公式スケジューラー」です。
公式のzpkgパッケージマネージャーでZima Cronをインストールする
IceWhaleのチュートリアルはZimaOSターミナルから開始し、次を使用します。
zpkg install zima_cronソースには、インストール後に再起動は必要ないと明記されています。その後、Zima CronはZimaOSのウェブインターフェースのアプリ一覧に表示されます。
zpkg.重要な処理をスケジュールする前に安全なテストタスクを作成する
公式チュートリアルでは、破壊的なメンテナンスコマンドではなく、安全な1分ごとのロギングタスクを意図的に使用しています。これは、どのスケジューラーでも有効な手順です。バックアップやサービスの再起動を自動化する前に、バックエンドが実行されること、スケジュールが正しく解釈されること、想定した場所に出力が書き込まれることを確認します。
公式の例では、ログファイルにタイムスタンプを追加します。
bash -c 'echo "$(date "+%Y-%m-%d %H:%M:%S") zima cron works" >> /DATA/zima_cron_test.log'このコマンドはテキストを追加するだけなので、アプリケーションの状態を変更せずにスケジューリングを検証するのに適しています。
単純な繰り返しにはインターバルスケジューリングを使用する
正確な実時刻が重要でない場合は、インターバルスケジュールが適しています。数分ごとの軽量なヘルスチェックや、数時間ごとのクリーンアップジョブなどが例です。
重要なタスクでは、「24時間ごと」が必ずしも「毎日午前4時」と同じではないことに注意してください。特にサービスの再起動後はその違いが現れます。特定の時刻が重要な場合は、cron式を使用してください。
カレンダーベースのスケジュールには標準のcron式を使用する
公式チュートリアルでは、標準的なcron構文についても説明しています。たとえば、次のように記述します。
*/5 * * * *5分ごとに実行されます。通常のcron式では、毎日、毎週、毎月、または曜日を指定したスケジュールを表現できるため、Zima Cronは固定間隔だけの場合よりも柔軟です。
複雑な式を導入する前に、無害なログ記録コマンドでテストし、少なくとも2回の実行が成功したことを確認してください。
Zima Cronと出力ファイルで実行を確認する
完全なテストでは、スケジューラーUIと想定される副作用の両方を確認する必要があります。たとえば、次のファイルに新しい行が追加されることを確認します。 /DATA/zima_cron_test.log。これにより、UI上ではタスクが存在していても、権限、パス、クォート、バイナリの欠落などが原因でコマンドが失敗するケースを検出できます。
アプリの再起動をスケジュールするには、適切なコマンド境界が必要
あるユーザーが、Home Assistantを毎日午前4時に再起動する方法を尋ねました。このスレッドでは、特定のインストール済みアプリを管理するためのIceWhale公式コマンドは提示されなかったため、この記事でそれを推測してはいけません。Zima Cronではシェルコマンドを実行できますが、アプリケーションに適した正確なコマンドは、そのアプリがZimaOSでどのように管理されているか、またアプリ管理レイヤーの外部から再起動しても安全かどうかによって異なります。
スケジューラーは、手動で動作を確認済みのコマンドに使用してください。最初のテストを本番アプリケーションの再起動にしないでください。
重大な注意点：再起動後にタスクを失ったユーザーもいる
1月26日、ZimaOS 1.5.3のユーザーから、再起動後に保存したタスクが消えるとの報告がありました。777-Spiderは、IceWhaleが問題を確認すると回答しました。その後、追加のユーザーも同様の挙動を再現し、単なる行き違いではなく、実際の信頼性に関わる懸念となりました。
その後、管理されたクリーンインストールでは、正常に動作したと報告されています。 zima-cron.service 有効な状態が続き、再起動後もタスクが表示されたままで、ログの記録も継続しました。これは有望に見えましたが、話はそこで終わりではありませんでした。
クリーンな環境でのテストと実環境でのテストでは、異なる結果が出た
後の参加者の1人は、次の方法でZima Cronをインストールしました。 zpkg、タスクを作成した後、再起動するとタスクが消え、新しいタスクを作成できなくなったと報告しました。そのサービス状態は次のようになっていました。
zima-cron.service
読み込み済み: 読み込み済み
アクティブ: 非アクティブ（停止）これは、サービスが自動起動しタスクが保持されたクリーンシステムでの結果と直接矛盾していました。適切な解釈は、保持の問題が環境やビルドに依存しており、すべてのユーザーについて決定的に解決されたわけではないということです。
再起動後に確認すべきこと
スレッドでは、サービスが引き続きアクティブか、またインストールが次の方法で正常に行われたかを確認するよう推奨されていました。 zpkg。重要な導入では、再起動後に最低限実施すべきQAは次のとおりです。
- ZimaOSマシンを意図的に再起動します。
- Zima Cronが引き続き表示されることを確認します。
- 保存したタスクが引き続き表示されることを確認します。
- バックエンドサービスがアクティブであることを確認します。
- 次に予定された実行を待ちます。
- UIのステータスだけでなく、タスクの実際の出力を確認してください。
保持に関する問題も公開で報告されました
Zima Cronプロジェクトには、再起動後にタスクが失われ、サービスが非アクティブになったことを説明する公開Issueがあります。無人メンテナンスを任せる前に、再起動後の保持に関する報告の現在の状況を確認してください。
テストしていないスケジューラーだけをバックアップの唯一の実行トリガーにしないでください
Zima Cronは自動化に便利ですが、再起動後にスケジュール済みのバックアップがひそかに消えるなら、実行されていないことが分かる手動バックアップより悪い結果になります。重要なタスクの場合は、スケジューラーのテストに加えて、独立したバックアップ状況の確認と復元検証を組み合わせてください。
Zima Cron FAQ
Zima Cronのインストールコマンドは公式ですか？
はい。 zpkg install zima_cron IceWhaleのチュートリアルで777-Spiderが公開しました。
通常のcron式を使用できますか？
はい。公式チュートリアルでは、間隔スケジュールと標準のcron式の両方に対応しています。
タスクは本当に再起動後も保持されますか？
元のスレッドから、普遍的な保証はできません。問題なく完了したクリーンなテストもあれば、タスクが繰り返し失われたり、サービスが非アクティブのままになったりした1.5.xシステムもありました。
重要なタスクを任せる前に、何をすべきですか？
実際に再起動テストを行い、タスクが定義されたままになっていることを確認し、その後コマンドが正常に実行されることを確認してください。
