Stödet för schemalagda uppgifter i ZimaOS utvecklades flera gånger efter att den här tråden startade. I februari 2025 skapade användare anpassade systemd-timers eftersom det saknades ett smidigt cron-gränssnitt. I mars meddelade Zima-Giorgio att dcron skulle läggas till och sade senare att det ingick i betaversionen av 1.4.0. År 2026 publicerade IceWhale en handledning för Zima Cron med ZimaOS pakethanterare för moduler, medan community-utvecklare senare skrev om schemaläggaren igen för att förbättra beständigheten och lägga till ett komplett webbgränssnitt.
Den praktiska lärdomen är inte ”installera cron med apt”. ZimaOS är ett oföränderligt appliance-operativsystem. Välj en schemaläggningsmetod som överlever den livscykel du faktiskt behöver – omstart, OTA-uppdatering eller omstart av modulen – och testa att den består innan du litar på den för säkerhetskopiering eller destruktivt underhåll.
Källanvändarna ville ha mer än en typ av schemalagda jobb
Användningsområden omfattade:
- daglig omstart;
- varje timme
chmod/chownskript; - Nextclouds bakgrundsjobb och RSS-uppdateringar;
- schemalagda säkerhetskopieringsskript;
- S.M.A.R.T.-tester;
- nattliga SnapRAID-jobb;
- startåtgärder som kolliderar med Pi-hole.
Dessa hanteras inte lika bra av en enda schemaläggare. Beroenden för starttjänster hanteras ofta bättre av systemd, medan periodiska användarkommandon passar cron-liknande schemaläggning.
systemd-timers från communityn fungerade och överlevde åtminstone vissa uppdateringar
WuzzyFeasel skapade en omstartstimer under /etc/systemd/system/ och rapporterade senare att anpassade systemd-timers överlevde en ZimaOS-uppdatering. Det var en värdefull bekräftelse från communityn.
Zima-Giorgio rekommenderade också specifikt systemd för ett startjobb när en användare ville att Pi-hole-relaterade åtgärder skulle köras efter uppstart.
IceWhale meddelade att dcron skulle komma till ZimaOS 1.4.0
Den 5 mars 2025 skrev Zima-Giorgio: ”dcron kommer att läggas till.” I april förtydligade han att dcron ingick i betaversionen av 1.4.0 och skulle läggas till i den stabila versionen.
Detta är ett officiellt historiskt produktuttalande, inte en gissning från communityn.
Att crontab finns tillgängligt garanterade inte beständiga användarjobb
Senare rapporterade användare av 1.5.x att crontab-poster försvann efter omstart eller att schemaläggarens uppgifter inte sparades på ett tillförlitligt sätt. Därför räcker det inte att bara se en crontab kommandot bevisar inte att användarens sparade jobb överlever den oföränderliga systemlivscykeln.
Starta alltid om en gång och kontrollera att uppgiften fortfarande finns innan du förlitar dig på den.
IceWhale publicerade senare en handledning för Zima Cron-modulen
I januari 2026 publicerade 777-Spider en separat handledning för Zima Cron med:
zpkg install zima_cronHandledningen omfattade schemaläggning med intervall och cron-uttryck samt uppgiftsloggar. Det var en schemaläggare på modulnivå, inte ett Debian-paket som installerades med APT.
Använd arbetsflödet för Zima Cron-modulen och den senare diskussionen innan du antar att ett visst modulnamn eller en viss version fortfarande är aktuell.
En omskrivning av Cron från communityn lade till ett komplett schemaläggargränssnitt
Lintuxs omskrivning v0.2.0 annonserade beständiga uppgifter, mallar, loggar, aviseringar, omförsök, beroenden, prioriteter och taggar. Den distribuerades som en cron.raw modul och kunde installeras med zpkg.
Den här modulen är community-programvara och är inte samma sak som IceWhales ursprungliga dcron-implementation.
ZimaOS 1.6.1 åtgärdade ett problem med modulernas tjänstestart efter omstart
IceWhales versionsanteckningar för 1.6.1 innehåller en korrigering av ett problem där moduler inte startade tjänster enligt tjänstepolicyn efter en omstart. Det är relevant för schemaläggarmoduler som behöver starta automatiskt igen efter en omstart.
Det bevisar inte att alla historiska fel med Cron-beständighet har försvunnit; det fastställer att plattformen senare åtgärdade problemet med modulernas tjänstestart.
Använd inte en oprövad schemaläggare som enda styrning av säkerhetskopieringen
En schemalagd säkerhetskopiering är bara användbar om:
- uppgiften finns kvar efter omstart/uppdatering;
- destinationen är monterad;
- kommandot returnerar en meningsfull status;
- loggar sparas;
- en återställning har testats.
Att automatisera ett skript som stoppar alla containrar orsakar också ett avbrott och kan lämna tjänster nere om skriptet misslyckas halvvägs.
chmod/chown varje timme är vanligtvis ett symtom, inte den bästa långsiktiga lösningen
Det ursprungliga inlägget gällde ägarändringar varje timme eftersom filer som kopierades från Windows inte kunde läsas av medieappen. En bättre lösning är att korrigera SMB-användar-/gruppbehörigheter samt UID/GID- och monteringsbehörigheter för containern, så att nya filer får användbar åtkomst redan från början.
En schemaläggare som upprepade gånger tillämpar rekursiva ägarändringar kan vara långsam och skada de behörigheter som en annan applikation förväntar sig.
Vilken schemaläggare bör du använda?
- Beroende av uppstart/start: föredra vid behov en korrekt utformad systemd-tjänst/timer.
- Enkel periodisk uppgift: använd en schemaläggare/modul som är tillgänglig och stöds i din aktuella ZimaOS-version.
- Komplext arbetsflöde: överväg en särskild automatiseringscontainer, men testa beständighet efter omstart och säkerheten kring Docker-socketen.
Vanliga frågor om ZimaOS Cron
Sade IceWhale officiellt att dcron skulle läggas till?
Ja. Zima-Giorgio sade att det ingick i betaversionen 1.4.0 och planerades för den stabila versionen.
Bestod varje senare crontab-uppgift efter omstarter?
Nej. Flera senare användare rapporterade förlorade jobb eller problem med schemaläggarens beständighet.
Är det mörka Scheduler-gränssnittet från 2026 en inbyggd IceWhale-funktion?
Det kom från en omskrivning av Cron-modulen från communityn och bör betraktas som programvara från tredje part.
