Har du ont om diskutrymme på Linux? Kontrollera dina loggar!

Snabblänkar

⭐ Varför tar loggar upp så mycket diskutrymme?

⭐ Hitta dina loggar

⭐ Hur Linux roterar loggfiler

⭐ Vilka loggar är säkra att radera?

⭐ Så här fixar du det som fyller upp dina loggar

Viktiga slutsatser

Linux-operativsystemet är känt för att generera betydande mängder loggdata, vilket kan konsumera betydande lagringskapacitet på hårddisken eller solid state-enheten.

Mekanismen i ditt system använder vanligtvis en metod för att komprimera arkiverade loggar för att spara lagringskapacitet på din enhet.

Genom att använda antingen kommandot journalctl eller tail -f kan man läsa igenom loggposter och lokalisera potentiellt störande processer, vilket möjliggör effektiv felsökning och problemlösning.

Trots att Linux-system uppfattas som smidiga och effektiva kan användare ibland råka ut för att tillgängligt lagringsutrymme töms i en oväntad takt. Det är viktigt att identifiera grundorsaken till sådana händelser genom att granska systemets loggfiler. Dessa register kan ge värdefulla insikter om potentiella orsaker och ge vägledning om hur man hanterar dem effektivt.

Varför tar loggarna upp så mycket diskutrymme?

Loggfiler spelar en avgörande roll i underhållet av ett Linux-system genom att ge insikter om dess funktioner och möjliggöra felsökning av eventuella problem. På samma sätt som Händelsevisaren i Windows, erbjuder Linux loggningsdaemoner ett sätt att övervaka systemaktiviteter och diagnostisera problem. Det är värt att notera att loggfiler vanligtvis inte förbrukar mycket lagringsutrymme eftersom de flesta distributioner har mekanismer på plats för att reglera deras diskanvändning.

Förr i tiden bestod Linux loggfiler vanligtvis av ren text. Men eftersom ett ökande antal framstående distributioner har övergått till att använda systemd för att hantera sina operativsystem, finns dessa loggfiler nu i binär form och övervakas av journald, som i sig är en systemd-tjänst. Beroende på vilken specifik distribution som används, kan antingen rsyslog eller syslog-ng användas som en alternativ metod för att hantera sådana loggdata.

För att spara lagringskapacitet på en dators hårddisk är det vanligt att system regelbundet arkiverar och tar bort föråldrade loggfiler som inte längre är relevanta eller nödvändiga. Denna process innebär att äldre data komprimeras och raderas för att göra plats för nyare information som kan vara av större betydelse.

Det antas ofta att loggfiler inte upptar någon större lagringskapacitet, men en avvikande operation kan generera loggposter i en takt som överstiger systemets förmåga att rotera och hantera dem på ett effektivt sätt.

Om du har upptäckt att ditt tillgängliga diskutrymme oväntat har minskat, och du inte kan identifiera några nyligen gjorda stora filnedladdningar som källan till detta problem, är det möjligt att en ansamling av data i din Linux-systemlogg är orsaken. För att lösa detta problem måste du fastställa vilket specifikt innehåll i dina systemloggar som förbrukar värdefullt lagringsutrymme och genomföra nödvändiga korrigerande åtgärder.

Kommandot du , när det används med alternativet -h , är ett effektivt sätt att fastställa hur mycket diskutrymme som för närvarande används av filer och kataloger inom en viss katalog eller över flera kataloger på ditt system.

 du -h /var/log 

Du får en uppräkning av alla underkataloger, tillsammans med deras sammanlagda lagringskapacitet:

Hitta dina loggar

Om du använder en modern Linux-distribution som använder systemd behöver du JournalTL (journalt) för att granska loggdata. Lagringsplatsen för dessa loggar beror på den specifika operativsystemvarianten och kan hittas i antingen katalogen ‘/var/log/journal’ eller katalogen ‘/run/log/journal’, vilka båda vanligtvis finns under root-filsystemvolymen.

För att komma åt loggfilerna via terminalen, ange “journald” i kommandotolken. Dessutom finns det flera praktiska kommandoradsalternativ för specifika ändamål. Om du t.ex. vill granska startmeddelandena använder du alternativet “-b”:

 journalctl -b 

Med flaggan -f kan användare granska systemets loggade meddelanden på ett direkt och uppdaterat sätt.

Om ditt operativsystem använder en annan initieringsmekanism än systemd, kommer loggfilerna att finnas i katalogen /var/log. Även om systemd används kan vissa program fortsätta att lagra sina loggdata i den här mappen. Loggfilerna är rena textdokument och kan läsas med hjälp av ett vanligt pagineringsverktyg, t.ex. “less”.

Till exempel, för att läsa systemloggen:

 less /var/log/syslog

Den fullständiga informationen i loggfilen, som består av flera rader som kan räknas i tusental, visas så att du kan ta del av den.

Man kan också följa utvecklingen live genom att använda tail-kommandots “-f”-modifierare och köra det aktuella kommandot på terminalen eller i kommandotolken.

 tail -f /var/log/syslog

Hur Linux roterar loggfiler

Förekomsten av filer i katalogen /var/log med etiketter som slutar på “log.N.gz”, där N representerar ett aritmetiskt värde, betyder att systemets mekanism för arkivering av föråldrade poster är i drift. Vanligtvis innehåller de flesta operativsystem en programvara som kallas “logrotate” som utför denna funktion självständigt. Logrotate kan konfigureras att köras antingen som en schemalagd uppgift som initieras av cron-daemon eller triggas med hjälp av en systemd-timer.

Logrotate aktiveras vanligtvis dagligen i de flesta distributioner, med den primära funktionen att komprimera arkiverade loggfiler med hjälp av gzip-teknik, som kan identifieras genom att filändelserna “.gz” läggs till de komprimerade filerna. Logrotate använder specifika tröskelvärden som ålder eller filstorlek för att avgöra när komprimering ska ske, samtidigt som ett ytterligare tröskelvärde implementeras för att rensa ut föråldrade loggfiler från systemet.

Standardinställningarna för logrotate bör vara tillräckliga för de flesta datoranvändare. De som vill justera dess funktion kan dock göra det genom att ändra konfigurationsfilen som finns på /etc/logrotate.conf i en övervakande kapacitet. Dessutom måste man överväga att ändra antingen systemets cron-schemaläggning eller systemd-timerkonfigurationer, vilket vanligtvis ligger inom serveradministratörernas ansvarsområde.

Det är bättre att fixa det som fyller upp dina loggar än att justera konfigurationsfiler för att spara diskutrymme. Om du absolut måste ändra konfigurationen kan du läsa logrotate manual page .

Vilka loggar är säkra att radera?

I fall där det är absolut nödvändigt att hitta ytterligare lagringsutrymme och standardprocedurerna har uttömts, kan man överväga att radera loggfiler som är komprimerade med gzip och som har filändelsen “.gz”. Med tanke på att dessa dokument rör systemets funktion måste de dock tas bort av en privilegierad användare. Kommandot “rm” kan användas för detta ändamål och kräver administrativa behörigheter för att kunna utföras effektivt.

 sudo rm /var/syslog/syslog.*gz 

Denna instruktion kommer att eliminera alla filer som har “syslog” i namnet och som slutar med “.gz”.

När kommandot sudo används för att utföra potentiellt skadliga eller destruktiva åtgärder, som att radera filer med rm , är det av yttersta vikt att vara extremt försiktig och noggrann för att undvika oavsiktliga konsekvenser som kan uppstå till följd av felaktig användning.

Det rekommenderas generellt att inte ta bort filer från systemkataloger utan att noggrant förstå de potentiella konsekvenserna, men att ta bort arkiverade loggfiler bör inte leda till några problem så länge de är frånvarande. Om ett problem skulle uppstå kan det dock vara nödvändigt att hämta information från tidigare loggposter för felsökning.

Så här åtgärdar du det som fyller upp dina loggar

En effektiv metod för att fastställa innehållet i loggfiler är att använda kommandona journalctl eller tail -f, med särskilt fokus på eventuella återkommande felmeddelanden som kan förekomma i dem.

För att lösa problemet med otillräckligt diskutrymme är det nödvändigt att identifiera och avsluta den felaktiga process som förbrukar lagringsutrymme. Om orsaken till problemet fortfarande är oklar kan det vara till hjälp att konsultera online-resurser eller söka hjälp från operativsystemets supportkanaler. När grundorsaken har lösts kan du eliminera föråldrade loggfiler och frigöra ytterligare lagringskapacitet utan risk. Med detta åtgärdat bör man uppleva en märkbar ökning av tillgängligt diskutrymme.