このスレッドが始まった後も、ZimaOSのスケジュールタスク対応は何度も進化しました。2025年2月には、使いやすいcron UIがなかったため、ユーザーはカスタムsystemdタイマーを作成していました。3月には、Zima-Giorgioが次のように発表しました。 dcron 追加されると述べられ、その後、1.4.0ベータ版に含まれていると説明されました。2026年までにIceWhaleはZimaOSのモジュールパッケージマネージャーを使ったZima Cronのチュートリアルを公開し、後にコミュニティの開発者が永続性を改善し、完全なWebインターフェースを追加するためにスケジューラーを再び書き直しました。
実践的な教訓は「aptでcronをインストールする」ことではありません。ZimaOSは不変のアプライアンスOSです。再起動、OTAアップデート、モジュールの再起動など、実際に必要なライフサイクルを乗り越えられるスケジューリング方法を選び、バックアップや破壊的なメンテナンスを任せる前に、その永続性をテストしてください。
情報源のユーザーが求めていたのは、1種類だけではないスケジュールジョブでした
用途には次のようなものがありました。
- 毎日の再起動。
- 毎時
chmod/chownスクリプト。 - NextcloudのバックグラウンドジョブとRSS更新。
- スケジュールされたバックアップスクリプト。
- S.M.A.R.T.テスト。
- 毎晩のSnapRAIDジョブ。
- Pi-holeの競合に対する起動時の処理。
これらは、1つのスケジューラーですべて同等に適切に処理できるものではありません。スタートアップサービスの依存関係にはsystemdのほうが適していることが多く、定期的なユーザーコマンドにはcron形式のスケジューリングが適しています。
コミュニティのsystemdタイマーは少なくとも一部のアップデート後も機能し、維持された
WuzzyFeaselは次の場所に再起動タイマーを作成しました。 /etc/systemd/system/ その後、カスタムsystemdタイマーがZimaOSのアップデート後も維持されたとの報告もありました。これは有用なコミュニティによる検証でした。
Zima-Giorgioは、ユーザーがPi-hole関連の処理を起動後に実行したいと考えていた際、スタートアップジョブには特にsystemdを推奨しました。
IceWhaleがZimaOS 1.4.0向けにdcronを発表
2025年3月5日、Zima-Giorgioは「dcronが追加されます」と書きました。4月には、dcronは1.4.0ベータ版に含まれており、安定版にも追加されると説明しました。
これはコミュニティの推測ではなく、公式の過去の製品説明です。
crontabが利用可能でも、ユーザージョブの永続性は保証されなかった理由です
その後、1.5.xのユーザーから、再起動後にcrontabのエントリが消えたり、スケジューラーのタスクが確実には保持されなかったりするとの報告がありました。これが、単に crontab このコマンドだけでは、保存したジョブが不変システムのライフサイクルを通じて保持されることは証明できません。
依存する前に、必ず一度再起動し、タスクが残っていることを確認してください。
IceWhaleが後にZima Cronモジュールのチュートリアルを公開
2026年1月、777-Spiderは次の内容を使ったZima Cronの別のチュートリアルを公開しました。
zpkg install zima_cronこのチュートリアルでは、間隔指定とcron式によるスケジューリングに加え、タスクログも扱っていました。これはAPTでインストールするDebianパッケージではなく、モジュールレベルのスケジューラーでした。
「Zima Cronモジュールのワークフローと、その後の議論」を確認してから、特定のモジュール名やバージョンが現在も有効だと判断してください。
コミュニティによるCronの書き直しで、フル機能のスケジューラーUIが追加された
Lintuxのv0.2.0の書き直し版では、永続タスク、テンプレート、ログ、通知、再試行、依存関係、優先度、タグが宣伝されていました。これは cron.raw モジュールであり、次のコマンドでインストールできました zpkg.
このモジュールはコミュニティ製ソフトウェアであり、IceWhaleが元々実装したdcronとは別物です。
ZimaOS 1.6.1でモジュールサービスの再起動問題を修正
IceWhaleの1.6.1リリースノートには、再起動後にmodモジュールがサービス方針に従ってサービスを起動しなかった問題の修正が含まれています。これは、再起動後に自動的に復帰する必要があるスケジューラーモジュールに関係します。
これは、過去のCron永続化バグがすべて解消されたことを証明するものではありません。後発のプラットフォーム修正により、モジュールサービスの起動動作が改善されたことを示すものです。
テストしていないスケジューラーを唯一のバックアップ管理手段として使用しないでください
スケジュール済みバックアップが役立つのは、次の条件を満たす場合のみです。
- タスクが再起動／更新後も保持されること。
- 保存先がマウントされていること。
- コマンドが意味のあるステータスを返すこと。
- ログが保持されること。
- 復元がテスト済みであること。
すべてのコンテナを停止するスクリプトを自動化すると、停止時間が発生し、スクリプトが途中で失敗した場合にサービスが停止したままになる可能性もあります。
毎時のchmod／chownは通常、症状であり、長期的な最善策ではありません
元の投稿者は、Windowsからコピーしたファイルをメディアアプリが読み取れなかったため、毎時所有者を変更したいと考えていました。より適切な設計は、SMBのユーザー／グループ権限と、コンテナのUID／GID／マウント権限を修正し、新しいファイルが最初から適切なアクセス権で作成されるようにすることです。
所有者を再帰的に変更するスケジューラーを繰り返し実行すると、処理が遅くなり、別のアプリケーションが想定する権限を損なう可能性があります。
どのスケジューラーを使うべきですか？
- 起動時の依存関係：適切な場合は、正しく設計されたsystemdサービスまたはタイマーを優先してください。
- 単純な定期タスク：現在のZimaOSリリースで利用でき、サポートされているスケジューラーまたはモジュールを使用してください。
- 複雑なワークフロー：専用の自動化コンテナを検討してください。ただし、再起動後の永続性とDockerソケットのセキュリティをテストしてください。
ZimaOS Cron FAQ
IceWhaleはdcronが追加されると公式に発表しましたか？
はい。Zima-Giorgioは、1.4.0ベータ版に含まれており、安定版にも採用予定だと述べました。
その後のcrontabタスクはすべて、再起動後も保持されましたか？
いいえ。その後、複数のユーザーからジョブの消失やスケジューラーの永続化に関する問題が報告されました。
2026年のダークテーマのScheduler UIは、IceWhaleの組み込み機能ですか？
これはコミュニティによるCronモジュールの書き直しから派生したものであり、サードパーティ製モジュールソフトウェアとして扱う必要があります。
