Egy hibásan működő PHP-szkript vagy bővítmény percenként több ezer figyelmeztetést írhat a naplóba, és a webhely mappáiban keletkező error_log fájlok néhány nap alatt gigabájtosra nőhetnek. Ez a cikk bemutatja, hogyan találja meg őket a find paranccsal, hogyan szabadítsa fel a helyet úgy, hogy közben ne okozzon újabb hibát, és mit tegyen, hogy ne nőjenek vissza.

A parancsokat egy AlmaLinux 10.2-es tesztgépen, egy mintakönyvtáron próbáltuk ki. A webhely mappájában (például ~/public_html) futtassa őket; a . mindig az aktuális könyvtárat jelenti.

Az aWh cPanel tárhelyein a PHP alapból a home könyvtár logs/php.error.log fájljába naplóz, a webhely mappáiban ezért ritkábban keletkezik error_log. Régebbi beállításoknál, más szervereken és egyes alkalmazásoknál viszont gyakori.

1. Az error_log fájlok listája méretükkel

find . -type f -name error_log -exec du -sh {} +

• -type f: csak fájlokat keres;
• -name error_log: csak a pontosan error_log nevűeket (a -iname a kis- és nagybetűtől függetlenül keres);
• -exec du -sh {} +: a talált fájlok méretét a du írja ki. A {} + a fájlokat egyetlen du hívásnak adja át, ami sok fájlnál gyorsabb, mint a {} \; (fájlonként egy hívás).

Az összes error_log együttes mérete:

find . -type f -name error_log -print0 | du -ch --files0-from=- | tail -1

2. Csak a nagyok: a -size kapcsoló

find . -type f -name error_log -size +100M -exec ls -lh {} \;

A -size +100M a 100 MB-nál nagyobb fájlokat adja. Gigabájtnál vigyázzon a mértékegységre:

• -size +1G az 1 GiB-nál (1 073 741 824 bájt) nagyobb fájlokat jelenti;
• -size +1000000000c (a c bájtot jelent) az 1 milliárd bájtnál nagyobbakat, ami valamivel kevesebb.

A teszten egy 1010 MB-os error_log-ot a -size +1000000000c megtalált, a -size +1G nem; egy 1,1 GB-osat mindkettő. A find felfelé kerekít, ezért a -size +1G az 1 GiB-os fájlt még nem, csak a nagyobbat találja meg. Pontosabb határhoz megabájtban adja meg: -size +1024M.

3. A hely felszabadítása: ürítés törlés helyett

Egy használatban lévő naplófájlt ne törölje (rm), hanem ürítse ki:

find . -type f -name error_log -size +100M -exec truncate -s 0 {} +

A truncate -s 0 nulla bájtra rövidíti a fájlt, a fájl maga megmarad. Ha egy futó program (a webszerver, a PHP-FPM) éppen nyitva tartja a naplót, a törölt fájl helye nem szabadul fel, amíg a program újra nem indul: a df szerint a lemez továbbra is tele lesz, a fájlt pedig már sehol nem látja. Ezt a jelenséget és a javítását a Betelt a lemez, de a du nem mutatja cikk mutatja be.

Ha mégis törölni szeretné, mert biztosan nem használja semmi (például egy régi, már nem létező alkalmazás mappájában):

find . -type f -name error_log -size +100M -delete

A törlés végleges, lomtár nincs. Futtatás előtt mindig nézze meg a listát a -delete nélkül.

4. Mielőtt kiüríti: nézze meg, mi van benne

A nagy error_log tünet, nem ok: ugyanaz a hiba néhány nap alatt újra megtölti. Az utolsó sorok megmutatják, melyik fájl és melyik sor okozza:

tail -n 20 error_log

A leggyakoribb üzenetek összesítése (a dátum nélkül):

cut -d']' -f2- error_log | sort | uniq -c | sort -rn | head

Ha a legtöbb sor PHP Deprecated vagy PHP Warning, a PHP-verzió és egy bővítmény verziója nem illik össze: frissítse a bővítményt vagy a sablont. Ha PHP Fatal error, a webhely egy része nem is működik. WordPressnél a hibakeresésről a WordPress hibakeresési mód (WP_DEBUG) cikk ír.

5. Hogy ne nőjön vissza

• Javítsa a hibát, amely a sorokat termeli (lásd az előző pontot).
• Éles webhelyen ne jelenítse meg és ne naplózza a figyelmeztetéseket tömegesen: a php.ini vagy .user.ini fájlban az error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE csak a fontos hibákat hagyja meg (lásd: A .user.ini fájl használata PHP-paraméterek beállítására).
• Saját szerveren a rendszer naplóit a logrotate forgatja és tömöríti; a webhelyek error_log fájljaira ez nem vonatkozik, hacsak külön szabályt nem ír nekik.

A teljes lemezhasználat vizsgálatáról a du és df parancsokat bemutató cikk, cPanel tárhelyen a Lemezhasználat ellenőrzése cPanelben cikk szól.