Volgens df -h wordt er in /home 131G gebruikt, en dat lijkt mij sterk. Want ik kan niks vinden wat zo groot is. Geen uit de kluiten gegroeide logfiles of iets dergelijks...
Iemand enig idee hoe dit komt?
Wel worden er met regelmaat logfiles aangemaakt die max. 10 MB zijn, en daarna een nieuwe aanmaken, waarbij er uitsluitend 10 logfiles bewaard blijven. Maar hoewel die verwijderd worden, zou het dan kunnen dan die ruimte bewaard blijft?
| 1 2 3 4 5 6 7 8 9 | [root@server1 home]# df -h Filesystem Size Used Avail Use% Mounted on /dev/root 20G 1.7G 17G 10% / devtmpfs 989M 0 989M 0% /dev tmpfs 990M 0 990M 0% /dev/shm tmpfs 990M 101M 889M 11% /run tmpfs 990M 0 990M 0% /sys/fs/cgroup /dev/sda2 439G 131G 286G 32% /home tmpfs 198M 0 198M 0% /run/user/0 |
Heb je ook de verborgen mappen bekeken?
du -hcx --max-depth 1 | sort -h
Voor zover ik weet wordt er in /home niks anders gelogd wat flinke proporties inneemt.quote:Op dinsdag 2 januari 2018 17:45 schreef Stratocruiser het volgende:
Welk filesystem gebruik je? Misschien worden er snapshots bewaard?
Heb je ook de verborgen mappen bekeken?
Ik gebruik ext4, en met deze extra switch zie ik wat meer data, geen idee of je hier wat meer over kan afleiden?
Bizar.. gewoon de verwachtte grootte:quote:
| 1 2 3 4 5 | [root@server1 home]# du -hcx --max-depth 1 | sort -h 16K ./lost+found 669M . 669M ./pietje 669M total |
| 1 2 3 4 5 6 7 8 9 | [root@server1~]# df -T Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/root ext4 20026236 1719404 17266500 10% / devtmpfs devtmpfs 1012684 0 1012684 0% /dev tmpfs tmpfs 1013140 0 1013140 0% /dev/shm tmpfs tmpfs 1013140 98348 914792 10% /run tmpfs tmpfs 1013140 0 1013140 0% /sys/fs/cgroup /dev/sda2 ext4 459913320 137970536 298557492 32% /home tmpfs tmpfs 202632 0 202632 0% /run/user/0 |
Hoe kan dit? Het lijkt dus dat de ruimte niet wordt vrijgegeven?
[ Bericht 3% gewijzigd door Claude_Viole op 02-01-2018 18:10:25 ]
In ieder geval geen snapshots, dat heeft EXT4 niet.quote:
[..]
Voor zover ik weet wordt er in /home niks anders gelogd wat flinke proporties inneemt.
Ik gebruik ext4, en met deze extra switch zie ik wat meer data, geen idee of je hier wat meer over kan afleiden?
[..]
Bizar.. gewoon de verwachtte grootte:
[ code verwijderd ]
[ code verwijderd ]
Hoe kan dit?
Gebruik je een GUI op je server?
Nope, alles gaat commandline! Hoezo wou je dat weten?quote:
[..]
In ieder geval geen snapshots, dat heeft EXT4 niet.
Gebruik je een GUI op je server?
Eigenlijk wat ver gezocht, zat te denken aan de prullenbak (~/.local/share/Trash) waar files in staan. Worden die logs dmv een script verwijderd?quote:
[..]
Nope, alles gaat commandline! Hoezo wou je dat weten?
[ Bericht 0% gewijzigd door #ANONIEM op 02-01-2018 18:16:41 ]
Jep, dat klopt! Ze roteren namelijk!quote:
[..]
Eigenlijk wat ver gezocht, zat te denken aan de prullenbak (~/.local/share/Trash) waar files in staan. Worden die logs dmv een script verwijderd?
Ik zal eens kijken, hoe kan ik dit het beste runnen? nog met bepaalde parameters?quote:
En met -N kan je het droog uitvoeren zonder de boel te wijzigen, nietwaar?
Het is trouwens een server die op 500 km afstadn staat ter info. Dus ik wil niks om zeep helpen...
[ Bericht 8% gewijzigd door Claude_Viole op 02-01-2018 18:46:54 ]
sudo touch /forcefsck
sudo reboot
Dat kan ff duren maar je server komt daarna vanzelf wel terug.
Een server met 200GB HDD waarvan er iets van 10% wordt gebruikt zal toch niet langer duren dan een uurtje of wat?
En hoe komt dit verschil nou eigenlijk precies?
ik neem aan dat die /forcefsck weer vanzelf wordt verwijderd na afloop, zodat ik niet in een loopje kom met rebooten
?Nee geen uur, denk eerder in minuten. En ja dat bestand wordt gewoon gewist.quote:
Ik zal eens even kijken morgen!
Een server met 200GB HDD waarvan er iets van 10% wordt gebruikt zal toch niet langer duren dan een uurtje of wat?
En hoe komt dit verschil nou eigenlijk precies?
ik neem aan dat die /forcefsck weer vanzelf wordt verwijderd na afloop, zodat ik niet in een loopje kom met rebooten
Weet ik ook niet, paar geflipte bitjes ofzo?quote:
Maar dan ben ik enkel nog benieuwd naar de reden waarom die waarde zo gigantisch fout is.
Ik ga sowieso komende week die logging wat temmen dat hij minder gaat schrijven. Hij logt iets teveel crap zie ik
.Gebeurde meestal als ik logs onder de voeten van een loggend proces wegmaaide (voor rotating) en vergat de betreffende processen een SIGHUP o.i.d. te geven zodat het e.e.a heropend/opgeschoond werd
Doe eens als het ff kan een graceful reload (of een restart, maar weet niet hoe belangrijk het proces is) van het proces dat die logfiles volschrijft, ben heel benieuwd naar je df output erna
[ Bericht 15% gewijzigd door Fleischmeister op 03-01-2018 17:11:00 ]
Opeens had ik de ruimte weer terug. van de week maar eens even het script temmen omdat hij een hoop bullshit logt.
Het verwijderd alleen de referentie ernaar. Als er nog andere verwijzingen naar dat bestand zijn (doordat een proces het nog geopend heeft bijvoorbeeld!) is het bestand gewoon nog aanwezig en neemt ruimte in. Het is alleen niet meer te vinden.
Pas als alle processen die nog zo’n bestand geopend hebben dat gesloten hebben is het bestand echt weg.
Dat los je dus niet op met minder logging, dat verkleint het probleem hooguit een beetje.
Je moet echt zorgen dat het loggende proces na de logrotatie het oude bestand sluit en het nieuwe bestand opnieuw opent. Ookal is dat een bestand met dezelfde naam.
Ja, dat kan heel goed.quote:
Wel worden er met regelmaat logfiles aangemaakt die max. 10 MB zijn, en daarna een nieuwe aanmaken, waarbij er uitsluitend 10 logfiles bewaard blijven. Maar hoewel die verwijderd worden, zou het dan kunnen dan die ruimte bewaard blijft?
Een file onder Linux/Ext4 is niet meer dan een link naar een inode. Als je de file delete, dan wordt alleen de link verwijderd en de link-count van de inode met 1 verlaagt. Als de link count v/d inode 0 is dan wordt de file daadwerkelijk verwijderd, maar pas als er geen file descriptors meer zijn die naar die inode wijzen.
Met andere woorden, als je een file delete die nog door een applicatie in gebruik is dan wordt de file niet verwijderd. Het kan dus zijn dat de applicatie die die logfiles schrijft/verwijderd deze niet netjes afsluit. In dat geval zal de desbetreffende applicatie ook file descriptors lekken en op een gegeven moment crashen wanneer het ingestelde max. aantal FD's voor die user bereikt is.
Je kan zien of er nog gedelete files in gebruik zijn met het volgende commando:
| 1 | lsof -nP +L1 |
Inmiddels is de logging nu getemd in de nieuwe update.
