Egy Suse 11.1 -es serverem van, a rendszer az SDA2-volumon, aminek 20 GB a merete. Azt vettem eszre, hogy a df azt mondja, hogy 96% tele van, ami lehetetlen. Egyenkent atnezve az USR 3,9GB, a VAR 2,2 GB,az opt 450MB, Proc 896 MB, az SRV 707 MB a tobbi nem lenyeges. De akkor mivel van tele? ls-l-e en nem latok semmi gyanusat, de akkor hova tunik a hely? Elore is koszi a segitseget. F.
- 142924 megtekintés
Hozzászólások
nem toroltel valami nagyobb fajlt anelkul hogy azt megnyito/hasznalo progit nem restartoltad? Mert ha igy van akkor amig a progi nincs ujrainditva addig nem szabadul fel a hely...
ez lehet ennek _egyik_ oka
- A hozzászóláshoz be kell jelentkezni
Jellemzően a logging facility-k működnek ilyeténképpen, ilyen tüneteket okozva. Azokat célszerű a fentiek értelmében újraindítani, és utána megnézni.
A filerendszer konzisztens? Egy fsck-t lehet, megérne. Azért ráereszthetsz egy rkhunter-t is; nyilván ez sem tévedhetetlen, fenntartásokkal kell kezelni.
- A hozzászóláshoz be kell jelentkezni
elromlott a tapom, es igy nem lett szabalyosan kikapcsolva a gep. Tettem bele uj tapot, de siman elindult, igy nem gyanakodtam semmire. Lehet hogy magserult a filerendszer (ext3) ?
- A hozzászóláshoz be kell jelentkezni
Hello !
Ha leállítható szerver, és fizikailag hozzáférsz, akkor valamilyen live linux rendszerrel nézd meg !
CSZ
- A hozzászóláshoz be kell jelentkezni
Nem csak meretre tud elfogyni a hely, hanem mennyisegre is, pl keves a szabad inode, block, anyamkinnya.
- A hozzászóláshoz be kell jelentkezni
lsof kimenetet se árt végignyalni.
--
Coding for fun. ;)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
fuser -d /
du -sk /* | sort -n
Meg nem artana a logokat is atnezned.
- A hozzászóláshoz be kell jelentkezni
A /proc-t ne számold bele, mert az csak virtuális "tárhely foglalás". A futó rendszer memóriatartalma van benne többek közt.
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
ha rootban kiadod
du-sh */$pwd
mit ad eredményül?
Nekem múlt héten a samba szerveren tünt el a hely, mert véletlenül 80GB fájlokat nyitottam meg és állítottam le, így /tmp/mc-root -ban leledzett egy 18GB fájl...
- A hozzászóláshoz be kell jelentkezni
Így jár aki mc-t használ :)
Régebben én is megtréfáltam magam egyszer-kétszer mc+nagy fájlokkal
--
http://laszlo.co.hu/
- A hozzászóláshoz be kell jelentkezni
A du parancsok segitettek megtalalni a valaszt - koszi -, a VAR van tele, merete 18G!! Szerintetek at lehet utolag particionalni a winchestert, nem tul kockazatos? Az sda3 particion boven van hely, az lecsokkentenem, az sda2-t meg megnovelnem.
- A hozzászóláshoz be kell jelentkezni
Én még mindig azt mondom, hogy állítsd le a logger daemon-okat, archiváld/töröld a logokat, utána indítsd el újra...feltéve, hogy azokkal telt meg, amit valószínűsítek. A másik lehetőség a csomagkezelőd helyi átmeneti tárolója. Nézd meg pontosan, a /var -on belül mi foglalja a helyet (du -hs /var*)! Ha logok, akkor célszerű valamiféle logrotate megoldást üzembe helyezni, a legtöbb disztribúcióban van ilyen ab ovo. Ha csomagok, akkor azokat is lehet purgálni akár kézzel, akár specifikus paranccsal is a csomagkezelőn keresztül a legtöbb esetben.
- A hozzászóláshoz be kell jelentkezni
+1 a csomagfájlokra (nálam épp /var/cache/apt/archives/)
Végére kell járni, mert azért 18 GB az 18 GB, nem szokásos logméret.
- A hozzászóláshoz be kell jelentkezni
Megtalaltam, es ezer bocs hogy magamtol nem gondoltam erre. Az egyik SAMBAt hasznalo WIN usernek roaming profilja volt - elfelejtettem kiirtani. Igy sikerult tobb mint 10G-t folmasolnia a VAR ala. Bocs megegyszer, de talan mas is okul ma hibambol. F.
- A hozzászóláshoz be kell jelentkezni