Tom for diskplass er den vanligste grunnen til at en server slutter å virke uten at noen har villet noe vondt. Nettstedet svarer 500, databasen skriver ikke, posten går ikke ut — og df -h viser samtidig noen ledige gigabyte. La oss gå gjennom tre tilfeller der det skjer, og samtidig det du bør vite om SMART.

Tilfelle én: inodene tok slutt

Et filsystem har to begrensede ressurser: plass til innhold og oppføringer om filer. Den andre tar slutt uavhengig av den første:

df -h
df -i

Er IUse% i den andre kommandoen 100, dreier det seg om inoder. Plassen finnes, men det er umulig å opprette en eneste fil, ikke engang en tom.

De skyldige er alltid de samme: millioner av bittesmå filer. PHP-økter i /var/lib/php/sessions der oppryddingen har gått i stykker. En applikasjonshurtigbuffer uten rensing. En låst e-postkø. En katalog med miniatyrbilder. Slik finner du dem:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

Kommandoen skriver ut katalogene med flest filer. På et stort system tar den noen minutter — det er normalt.

Tilfelle to: filen er slettet, men plassen kom ikke tilbake

En mer lumsk situasjon. Noen slettet en oppsvulmet logg med rm, men prosessen som skrev til den, holder den fortsatt åpen. Filen finnes ikke lenger i katalogen, plassen forblir opptatt, og slik er det til prosessen startes på nytt.

sudo lsof +L1

Kommandoen viser filer uten referanser i filsystemet som likevel holdes av en prosess. Det bøtes med en omstart eller en myk omlasting av den prosessen, ikke med leting etter «hvor ble det av gigabytene».

Derav regelen: en oppsvulmet logg slettes ikke, men nullstilles — da forblir den åpne filhåndtaket brukbart:

sudo truncate -s 0 /var/log/huge.log

Og rett etterpå setter man opp rotasjon, ellers gjentar alt seg om en uke.

Tilfelle tre: loggene spiste det opp

Hvor plassen nøyaktig tok veien, ses når man går nivå for nivå:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

Flagget -x hindrer nedstigning i andre filsystemer; uten det kryper tellingen inn i /proc og i monterte nettverksressurser. Enklere er det å gjøre alt dette i ncdu hvis det er tilgjengelig.

De vanlige slukene:

  • journald. Én kommando avgjør: journalctl --disk-usage. Begrenses med linjen SystemMaxUse=500M i /etc/systemd/journald.conf, engangsrensing med journalctl --vacuum-size=200M;
  • sikkerhetsverktøyenes logger. Suricata skriver med standardoppsettet tretti typer hendelser og setter ikke opp rotasjon etter seg — på en virkelig server ble det 15 GB på to døgn. Det samme skjer med audit.log og med nginx' feilsøkingslogger;
  • sikkerhetskopier som legges på samme disk og aldri slettes;
  • apt-hurtigbufferen — apt clean gir iblant tilbake et par gigabyte.

Særskilt om /boot

En liten partisjon som fylles av gamle kjerner. I seg selv feller den ikke nettstedet, men den stopper oppdateringene helt: den nye kjernen installeres ikke, og bak den står hele pakkekøen stille. Det bøtes med apt autoremove --purge og forebygges ved å slå på automatisk fjerning av ubrukte kjerner i innstillingene for automatiske oppdateringer.

SMART: hvilke attributter som betyr noe

Først et forbehold: på en virtuell server er SMART som regel utilgjengelig — disken er virtuell, og den fysiske ses ikke under den. Det er ikke en feil, det finnes bare ingen data. Alt nedenfor gjelder dedikerte servere og egen maskinvare.

sudo smartctl -a /dev/sda

Linjen SMART overall-health self-assessment test result: PASSED er ingen grunn til ro: den forblir grønn praktisk talt helt fram til havariet. Det man skal se på, er de enkelte tellerne:

  • 5, Reallocated_Sector_Ct — omplasserte sektorer. En verdi som ikke er null, betyr at disken allerede holder på å ryke; vokser den over tid — bytt uten opphold;
  • 197, Current_Pending_Sector — uleselige sektorer som venter på avgjørelse. Den mest urovekkende av alle: den betyr som regel at noen data allerede ikke lar seg redde;
  • 198, Offline_Uncorrectable — det samme, bekreftet av en kontroll;
  • SSD: Percentage Used / Media_Wearout_Indicator — oppbrukt skrivekapasitet. En forutsigbar størrelse man planlegger byttet etter.

Temperatur og driftstimer sier derimot ingenting i seg selv: en disk med fem års drift og nullstilte feiltellere er sikrere enn en ny med ett-tall i attributt 197.

Poenget med å følge med

Alt ovenfor er reaksjon på det som allerede har skjedd. Samtidig er både diskens oppfylling og SSD-ens slitasje langsomme og fullstendig forutsigbare forløp: en kurve over plassen de siste to ukene viser datoen da plassen tar slutt, lenge før det skjer. Forskjellen mellom «nettstedet har ligget nede siden tre om natten» og «på torsdag må loggene ryddes» er bare å ha et tall foran øynene. Hvordan det ser ut i sin helhet, viser demonstrasjonssiden nedenfor.