Obsługa zaplanowanych zadań w ZimaOS ewoluowała kilkakrotnie od rozpoczęcia tego wątku. W lutym 2025 roku użytkownicy tworzyli niestandardowe timery systemd, ponieważ nie było wygodnego interfejsu cron. W marcu Zima-Giorgio ogłosił, że dcron miał zostać dodany, a później poinformowano, że był zawarty w wersji beta 1.4.0. Do 2026 roku firma IceWhale opublikowała samouczek Zima Cron wykorzystujący menedżera pakietów modułów ZimaOS, a później deweloperzy społecznościowi ponownie przepisali harmonogram, aby poprawić trwałość i dodać pełny interfejs internetowy.
Praktyczny wniosek nie brzmi: „zainstaluj cron za pomocą apt”. ZimaOS to niezmienny system operacyjny typu appliance. Wybierz metodę planowania, która przetrwa cykl życia wymagany w danym przypadku — ponowne uruchomienie, aktualizację OTA, ponowne uruchomienie modułu — i przetestuj tę trwałość, zanim powierzysz jej kopie zapasowe lub destrukcyjne czynności konserwacyjne.
Użytkownicy źródłowi potrzebowali więcej niż jednego rodzaju zaplanowanych zadań
Przypadki użycia obejmowały:
- codzienne ponowne uruchamianie;
- co godzinę
chmod/chownskrypty; - zadania w tle Nextcloud i aktualizacje kanałów RSS;
- zaplanowane skrypty kopii zapasowych;
- testy S.M.A.R.T.;
- nocne zadania SnapRAID;
- działania uruchamiane przy starcie systemu w przypadku konfliktów z Pi-hole.
Nie wszystkie te zadania są równie dobrze obsługiwane przez jeden harmonogram. Zależności usług uruchamianych przy starcie systemu często lepiej obsługiwać za pomocą systemd, natomiast okresowe polecenia użytkownika pasują do planowania w stylu cron.
Timery systemd społeczności działały i przetrwały co najmniej niektóre aktualizacje
WuzzyFeasel utworzył timer ponownego uruchamiania w katalogu /etc/systemd/system/ a później zgłosili, że niestandardowe timery systemd przetrwały aktualizację ZimaOS. Było to przydatne potwierdzenie ze strony społeczności.
Zima-Giorgio zalecił także konkretnie systemd w przypadku zadania uruchamianego przy starcie systemu, gdy użytkownik chciał, aby działania związane z Pi-hole wykonywały się po uruchomieniu.
IceWhale zapowiedziało dcron dla ZimaOS 1.4.0
5 marca 2025 roku Zima-Giorgio napisał: „dcron zostanie dodany”. W kwietniu doprecyzował, że dcron był zawarty w wersji beta 1.4.0 i zostanie dodany do wydania stabilnego.
To oficjalne historyczne stwierdzenie dotyczące produktu, a nie domysł społeczności.
Dostępność crontab nie gwarantowała trwałości zadań użytkownika
Późniejsi użytkownicy wersji 1.5.x zgłaszali, że wpisy crontab znikały po ponownym uruchomieniu albo zadania harmonogramu nie zachowywały się niezawodnie. Dlatego samo zobaczenie crontab polecenie nie dowodzi, że zapisane zadania użytkownika przetrwają cykl życia niezmiennego systemu.
Zawsze uruchom ponownie system i sprawdź, czy zadanie nadal istnieje, zanim zaczniesz na nim polegać.
IceWhale opublikował później samouczek dotyczący modułu Zima Cron
W styczniu 2026 roku 777-Spider opublikował osobny samouczek dotyczący Zima Cron, korzystając z:
zpkg install zima_cronSamouczek obejmował planowanie według interwałów i wyrażeń cron, a także dzienniki zadań. Był to harmonogram działający na poziomie modułu, a nie pakiet Debiana instalowany za pomocą APT.
Przed założeniem, że konkretna nazwa lub wersja modułu jest nadal aktualna, zapoznaj się z przebiegiem pracy z modułem Zima Cron i późniejszą dyskusją na jego temat.
Przepisany przez społeczność moduł Cron dodał pełny interfejs użytkownika Harmonogramu
Przepisana przez Lintux wersja v0.2.0 reklamowała trwałe zadania, szablony, dzienniki, powiadomienia, ponowienia, zależności, priorytety i tagi. Była rozpowszechniana jako cron.raw moduł i można go było zainstalować za pomocą zpkg.
Ten moduł jest oprogramowaniem społecznościowym, a nie tym samym co pierwotna implementacja dcron firmy IceWhale.
ZimaOS 1.6.1 naprawił problem z ponownym uruchamianiem usług modułów
Informacje o wydaniu IceWhale 1.6.1 zawierają poprawkę, dzięki której moduły mod po ponownym uruchomieniu nie uruchamiały usług zgodnie z zasadami usług. Ma to znaczenie dla modułów harmonogramu, które po restarcie muszą automatycznie powrócić do działania.
Nie dowodzi to, że zniknęły wszystkie historyczne błędy zachowywania zadań Cron; potwierdza późniejszą poprawkę platformy dotyczącą zachowania uruchamiania usług modułów.
Nie używaj nieprzetestowanego harmonogramu jako jedynego kontrolera kopii zapasowych
Zaplanowana kopia zapasowa jest przydatna tylko wtedy, gdy:
- zadanie jest zachowywane po ponownym uruchomieniu/aktualizacji;
- miejsce docelowe jest zamontowane;
- polecenie zwraca znaczący status;
- dzienniki są przechowywane;
- przywracanie zostało przetestowane.
Automatyzacja skryptu zatrzymującego wszystkie kontenery również powoduje przestój i może pozostawić usługi wyłączone, jeśli skrypt zakończy się niepowodzeniem w połowie działania.
Godzinne wykonywanie chmod/chown jest zwykle objawem, a nie najlepszym długoterminowym rozwiązaniem
Autor pierwotnego wpisu chciał zmieniać właściciela co godzinę, ponieważ pliki skopiowane z systemu Windows nie były odczytywane przez aplikację multimedialną. Lepszym rozwiązaniem jest poprawienie uprawnień użytkownika/grupy SMB oraz uprawnień UID/GID i montowania kontenera, aby nowe pliki od początku były tworzone z użytecznym dostępem.
Harmonogram, który wielokrotnie stosuje rekurencyjne zmiany właściciela, może działać wolno i uszkadzać uprawnienia oczekiwane przez inną aplikację.
Którego harmonogramu należy użyć?
- Zależność od uruchomienia systemu: w odpowiednich przypadkach preferuj prawidłowo zaprojektowaną usługę lub timer systemd.
- Proste zadanie okresowe: użyj harmonogramu/modułu dostępnego i obsługiwanego w bieżącej wersji ZimaOS.
- Złożony przepływ pracy: rozważ dedykowany kontener automatyzacji, ale przetestuj zachowanie po ponownym uruchomieniu oraz bezpieczeństwo gniazda Dockera.
FAQ dotyczące Cron w ZimaOS
Czy IceWhale oficjalnie poinformowało, że dcron zostanie dodany?
Tak. Zima-Giorgio powiedział, że funkcja została dołączona do wersji beta 1.4.0 i planowano ją w wydaniu stabilnym.
Czy każde późniejsze zadanie crontab było zachowywane po ponownym uruchomieniu?
Nie. Kilku późniejszych użytkowników zgłosiło utratę zadań lub problemy z zachowaniem harmonogramu.
Czy ciemny interfejs użytkownika Harmonogramu z 2026 roku jest wbudowaną funkcją IceWhale?
Pochodziło to z przepisanej przez społeczność wersji modułu Cron i należy traktować to jako oprogramowanie modułu firmy zewnętrznej.
