Ruimtegebrek is de vaakst voorkomende reden waarom een server ophoudt te werken zonder enige kwade opzet. De site geeft 500, de database schrijft niet, de mail gaat niet uit, en df -h meldt intussen enkele vrije gigabytes. Laten we de drie gevallen langsgaan waarin dat gebeurt, en meteen wat u over SMART moet weten.

Geval één: de inodes zijn op

Een bestandssysteem houdt twee begrensde hulpbronnen bij: ruimte voor de inhoud en registraties over de bestanden. De tweede raakt onafhankelijk van de eerste op:

df -h
df -i

Is IUse% in het tweede commando 100, dan gaat het om de inodes. Er is ruimte, maar er kan geen enkel bestand worden aangemaakt, zelfs geen leeg.

De schuldigen zijn altijd dezelfde: miljoenen piepkleine bestanden. PHP-sessies in /var/lib/php/sessions waarvan het opruimen kapot is. Een toepassingscache die nooit wordt geleegd. Een vastgelopen mailwachtrij. Een map met miniaturen. Zo vindt u ze:

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

Het commando somt de mappen met de meeste bestanden op. Op een groot systeem duurt het minuten — dat is normaal.

Geval twee: het bestand is verwijderd en de ruimte kwam niet terug

De verraderlijkere situatie. Iemand verwijderde met rm een uit de hand gelopen logboek, maar het proces dat erin schreef houdt het nog open. Het bestand staat niet meer in de map, de ruimte blijft bezet, en dat blijft zo tot het proces wordt herstart.

sudo lsof +L1

Het commando toont bestanden zonder verwijzing in het bestandssysteem maar nog wel vastgehouden door een proces. De remedie is dat proces herstarten of rustig herladen, niet zoeken naar «waar zijn de gigabytes gebleven».

Vandaar de regel: een uit de hand gelopen logboek wordt niet verwijderd maar geleegd — dan blijft de open verwijzing bruikbaar:

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

En richt meteen daarna rotatie in, anders herhaalt het zich binnen een week.

Geval drie: de logboeken hebben het opgegeten

Waar de ruimte precies is gebleven, ziet u door niveau voor niveau af te dalen:

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

De optie -x voorkomt uitstapjes naar andere bestandssystemen; zonder die kruipt de telling /proc en netwerkkoppelingen in. Dit alles gaat prettiger in ncdu, als dat beschikbaar is.

De gebruikelijke veelvraten:

  • journald. Eén commando klaart het: journalctl --disk-usage. Begrenzen doet u met de regel SystemMaxUse=500M in /etc/systemd/journald.conf, eenmalig opruimen met journalctl --vacuum-size=200M;
  • de logboeken van beveiligingshulpmiddelen. Suricata schrijft met de standaardconfiguratie dertig soorten gebeurtenissen en richt zelf geen rotatie in — op een echte server leverde dat 15 GB in twee dagen op. Hetzelfde geldt voor audit.log en voor foutopsporingslogboeken van nginx;
  • reservekopieën die op dezelfde schijf worden neergezet en nooit verwijderd;
  • de apt-cache — apt clean geeft soms een paar gigabyte terug.

Een woord over /boot

Een kleine partitie die volloopt met oude kernels. De site gaat er op zichzelf niet van onderuit, maar de updates komen wel volledig stil te liggen: de nieuwe kernel installeert niet en daarachter blijft de hele pakketwachtrij hangen. Verholpen met apt autoremove --purge, en voorkomen door het automatisch verwijderen van ongebruikte kernels aan te zetten in de instellingen voor automatische updates.

SMART: welke waarden ertoe doen

Eerst een voorbehoud: op een virtuele server is SMART meestal niet beschikbaar — de schijf is virtueel en de fysieke eronder ziet u niet. Dat is geen storing, er zijn eenvoudigweg geen gegevens. Al het volgende betreft toegewijde servers en eigen hardware.

sudo smartctl -a /dev/sda

De regel SMART overall-health self-assessment test result: PASSED is geen reden om te ontspannen: die blijft praktisch tot de storing groen. Waar u naar moet kijken zijn de concrete tellers:

  • 5, Reallocated_Sector_Ct — hertoegewezen sectoren. Niet nul betekent dat de schijf al achteruitgaat; groeit de waarde, vervang hem dan zonder uitstel;
  • 197, Current_Pending_Sector — onleesbare sectoren die op een beslissing wachten. De verontrustendste van allemaal: doorgaans betekent het dat een deel van de gegevens al niet meer te herstellen is;
  • 198, Offline_Uncorrectable — hetzelfde, bevestigd door een controle;
  • SSD: Percentage Used / Media_Wearout_Indicator — de verbruikte schrijfduurzaamheid. Een voorspelbare grootheid, waarop vervanging wordt gepland.

Temperatuur en bedrijfsuren zeggen daarentegen op zichzelf niets: een schijf met vijf jaar dienst en foutentellers op nul is betrouwbaarder dan een nieuwe met een 1 in waarde 197.

De zin van het meekijken

Al het bovenstaande is een reactie op wat al is gebeurd. Zowel het vollopen van een schijf als de slijtage van een SSD zijn echter trage, uitstekend voorspelbare processen: een bezettingsgrafiek over twee weken wijst de datum aan waarop de ruimte opraakt, lang voordat het zover is. Het verschil tussen «de site ligt eruit sinds drie uur ’s nachts» en «donderdag moeten de logboeken worden opgeruimd» is alleen het getal voor ogen hebben. Hoe dat samengebracht oogt, toont de demopagina hieronder.