No space left on device. Znamy to.

Baza przestaje zapisywać, logi się nie rotują, Docker odmawia współpracy, a Ty nie masz bladego pojęcia, co właściwie zapchało dysk, bo przecież “nic tam nie wrzucałeś”. Spokojnie. Winowajcę da się namierzyć w kilka minut, a poniżej masz trzy narzędzia, od najbardziej ogólnego do najbardziej szczegółowego.

Ile w ogóle zostało miejsca# 

df -h

-h (human-readable) to rozmiary w GB i MB zamiast nic niemówiących bajtów. Na Mikrusie patrz przede wszystkim na wiersz z /, bo to Twój główny dysk. Ktoś, kto dokupił Storage, zobaczy jeszcze osobną pozycję z /storage.

Które katalogi są największe (du)#

Rozmiar pojedynczego katalogu:

du -sh /var/log

Tylko że sprawdzanie katalogów jeden po drugim to zajęcie dla bardzo cierpliwych. Dużo sensowniej od razu wylistować wszystkie podkatalogi i posortować je od największego:

du -h --max-depth=1 /var | sort -rh

--max-depth=1 ogranicza wynik do pierwszego poziomu, bo bez tego du zasypie Cię listą każdego pliku z osobna. sort -rh sortuje malejąco i, co ważne, rozumie, że “1.8G” to więcej niż “530M”.

Mamy największy podkatalog? Świetnie. Powtarzasz to samo, tylko na nim (np. du -h --max-depth=1 /var/cache | sort -rh), i tak piętro po piętrze, aż dojdziesz do sedna.

Wygodne przeglądanie na żywo (ncdu)#

Przyznam szczerze: ręczne schodzenie z du mnie nudzi. Dlatego sam prawie zawsze od razu odpalam ncdu, które robi dokładnie to samo, tyle że w interaktywnym okienku, po którym łazisz strzałkami:

sudo apt install ncdu
ncdu /

Strzałki do poruszania się, Enter wchodzi głębiej, q zamyka. Jest też d, które kasuje zaznaczony plik lub katalog prosto z poziomu ncdu. Ostrożnie z nim. Żadnego kosza, żadnego “cofnij”.

Szukanie konkretnych dużych plików (find)#

Bywa i tak, że żaden katalog specjalnie nie odstaje, za to po całym systemie porozrzucane są pojedyncze kolosy. Wyłuskasz je tak (wszystko powyżej 100 MB):

find / -xdev -type f -size +100M -exec ls -lh {} \;

Rozbiórka na części:

  • -xdev - trzyma się jednego systemu plików. Przydatne, gdy masz podmontowany Storage i nie chcesz przy okazji przetrząsać również jego.
  • -type f - wyłącznie pliki.
  • -size +100M - próg wielkości, zmień wedle potrzeb.
  • -exec ls -lh {} \; - przy każdym znalezisku wypisuje jego rozmiar w czytelnej postaci.

Typowi winowajcy na VPS-ie#

Z naszego doświadczenia lista podejrzanych jest krótka i powtarzalna.

Na czele /var/log, zwłaszcza gdy jakaś usługa wpadła w pętlę i sypie tym samym błędem kilka razy na sekundę. Ile zajmuje journal, powie Ci journalctl --disk-usage.

Tuż za nim Docker, a konkretnie /var/lib/docker. Nieużywane obrazy i warstwy po buildach potrafią spuchnąć do kilku gigabajtów, zanim ktokolwiek się zorientuje. Na to jest docker system prune.

Dalej stare dumpy baz danych, porzucone kiedyś w /root albo /home “tylko na chwilę”. Wiadomo, jak to z tymi chwilami bywa.

No i /var/cache/apt, czyli pobrane paczki .deb. Tu wystarczy apt clean.

Najczęstsze błędy#

du mieli bez końca. Na dużym dysku skanowanie wszystkiego naraz trwa wieki. Dodaj --max-depth=1 i schodź w dół stopniowo.

df twierdzi, że dysk jest pełny, a du pokazuje dużo mniej. Ten przypadek potrafi napsuć krwi. Niemal zawsze chodzi o plik, który został usunięty, ale jakiś proces dalej trzyma go otwartego, więc system nie może zwolnić miejsca, dopóki proces go nie puści albo nie zostanie zrestartowany. Takie pliki-widma wskaże lsof +L1 2>/dev/null.

Coś zniknęło przez d w ncdu. Przykro mi, tego się nie odkręci. Jeśli nie wiesz, co to za plik, wyjdź z ncdu i najpierw mu się przyjrzyj.