Vad får schemalagda jobb att köras på värden men inte inuti en container?
Schemalagda jobb misslyckas i en container när schemaläggaren, miljön, användaren, tiden eller den nödvändiga körvägen skiljer sig från värdens fungerande kontext.
Ett kommando som fungerar i ett interaktivt skal på värden kan vara beroende av värdens PATH, inloggningsprofil, tidszon, monterade filer, autentiseringsuppgifter, DNS eller en långkörande cron-daemon. I en container är inget av detta garanterat. Börja med att kontrollera att en schemaläggarprocess körs och kör sedan det exakta jobbet med samma minimala miljö och användare som cron använder.
Bekräfta att en schemaläggarprocess faktiskt körs
Inspektera containerns aktiva processer och startkommando. Att installera cron-paket i avbildningen startar inte daemonen, och en container kör normalt endast den konfigurerade startpunkten eller det konfigurerade kommandot.
Stack Overflows långvariga Docker-diskussion om cron handlar om behovet av att köra en schemaläggare i containern i stället för att anta att värdens tjänst styr containerns crontab. Den första kontrollen är om cron-processen är aktiv när den schemalagda tiden infaller.
Om ingen schemaläggare körs väljer du en medveten utformning: kör cron eller en containeranpassad schemaläggare som förgrundsprocess, använd en separat jobbcontainer eller anropa applikationscontainern från värdens cron. Lägg inte till ytterligare en daemon utan kontroll utan att bestämma hur den ska loggas och stoppas.
Kör det exakta kommandot med en minimal miljö
Kopiera det schemalagda kommandot och kör det i containern som den avsedda jobbanvändaren med en rensad miljö. Fånga stdout, stderr, avslutskod, aktuell katalog och miljövariabler.
Containerbaserade cron-jobb misslyckas ofta eftersom cron inte läser in det interaktiva skalets profil, som tillhandahöll PATH, språk- och körningsmiljöer, API-token eller applikationsvariabler. En containerfokuserad guide om schemaläggning betonar att den nödvändiga jobbmijön måste bevaras.
Om kommandot endast misslyckas i den minimala miljön lägger du till uttryckliga absoluta sökvägar och de variabler som verkligen krävs. Undvik att läsa in en fullständig användarprofil som introducerar orelaterade alias, promptar eller hemligheter.
Kontrollera PATH, skal, arbetskatalog och användare
Ersätt relativa kommandon och filsökvägar med absoluta. Bekräfta att det valda skalet finns och att crontab-syntaxen stämmer med den cron-implementation som är installerad i avbildningen.
Kör jobbet som den konfigurerade cron-användaren och testa läs-, skriv- och körbehörighet för skript, konfigurationer, socketar och utdatakataloger. Ett manuellt test som root bevisar inte att ett schemalagt jobb utan privilegier kan slutföras.
Ange arbetskatalogen i kommandot eller omslagsskriptet. Om jobbet fungerar efter att endast katalogen eller användaren ändrats ska du behålla denna uttryckliga kontext i versionshanterad konfiguration i stället för att förlita dig på containerns standardvärden.
Jämför containerns tid och tidszon med schemat
Skriv ut aktuell tid, tidszon och nästa avsedda körning i containern. Containrar delar värdens kärnklocka men kan använda UTC eller andra tidszonsfiler för visning och tolkning av cron.
Ett fall på Server Fault visar hur containertid kan visas i en annan tidszon även när värden visar lokal tid, vilket får en korrekt crontab att köras vid fel lokal klockslag.
Välj en tydlig tidszonsstrategi och verifiera den efter att containern skapats på nytt. Kompensera inte genom att flytta cron-uttrycket medan den underliggande tidszonen förblir oklar, eftersom sommartid eller ändringar i avbildningen kan flytta körningen igen.
Verifiera monteringar, hemligheter, nätverksåtkomst och containerns livslängd
Kontrollera att alla indatakataloger, utdatasökvägar, hemligheter, socketar och konfigurationsfiler finns i containern när jobbet körs. Testa sedan åtkomst till DNS, databaser, API:er eller NAS från samma containernätverk.
Värdens cron kan se sökvägar på värden som saknas i containern. Ett Nextcloud-fall med Docker visar hur ett bakgrundsjobb kan verka vara konfigurerat medan det faktiska containerkommandot, användaren eller applikationssökvägen fortfarande hindrar den förväntade bakgrundskörningen.
Bekräfta också att containern fortfarande kör när schemat infaller. Kortlivade applikationscontainrar och ersättningar vid driftsättning kan avsluta en intern schemaläggare innan långvariga eller sällan förekommande jobb hinner slutföras.
Välj en schemaläggningsgräns och bevisa att den kör obevakat
Använd en enda ägare för schemat: värdens cron som anropar docker exec, en dedikerad schemaläggarcontainer eller en förgrundsschemaläggare i applikationsavbildningen. Dubbla schemaläggare kan köra samma underhållsuppgift två gånger.
ZimaSpaces guide om DNS-testning på containersidan tar upp en bakomliggande orsak när schemaläggaren startar men inte kan nå en annan tjänst.
Problemet är löst först när jobbet körs vid avsedd tid efter att containern skapats på nytt och värden startats om, genererar fångade loggar, använder förväntad användare och sökvägar och skapar det verifierade resultatet i applikationen. Ett lyckat manuellt kommando är inte slutförandet av testet.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
