abonnementen ibood.com bol.com Coolblue
  dinsdag 2 januari 2018 @ 12:24:41 #1
418311 Claude_Viole
Loopt te kloten...
pi_176234014
registreer om deze reclame te verbergen
Ik heb het idee dat de gebruikte ruimte op mijn CentOS server niet helemaal klopt.
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
[[email protected] 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
Verveel je je? Check dan deze site!
  dinsdag 2 januari 2018 @ 17:45:40 #2
312852 Stratocruiser
Klootzak-engineer from NASA
pi_176240865
Welk filesystem gebruik je? Misschien worden er snapshots bewaard?
Heb je ook de verborgen mappen bekeken?
pi_176241125
Je kan even uitzoeken welke map de ruimte gebruikt.

du -hcx --max-depth 1 | sort -h
  dinsdag 2 januari 2018 @ 18:02:14 #4
418311 Claude_Viole
Loopt te kloten...
pi_176241154
registreer om deze reclame te verbergen
quote:
0s.gif 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?
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?

quote:
0s.gif Op dinsdag 2 januari 2018 18:00 schreef Farenji het volgende:
du -hcx --max-depth 1 | sort -h
Bizar.. gewoon de verwachtte grootte:
1
2
3
4
5
[[email protected] 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
[[email protected]~]# 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 ]
Verveel je je? Check dan deze site!
  dinsdag 2 januari 2018 @ 18:10:09 #5
312852 Stratocruiser
Klootzak-engineer from NASA
pi_176241253
quote:
0s.gif Op dinsdag 2 januari 2018 18:02 schreef Claude_Viole het volgende:

[..]

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?
In ieder geval geen snapshots, dat heeft EXT4 niet.

Gebruik je een GUI op je server?
  dinsdag 2 januari 2018 @ 18:10:41 #6
418311 Claude_Viole
Loopt te kloten...
pi_176241260
quote:
0s.gif Op dinsdag 2 januari 2018 18:10 schreef Stratocruiser het volgende:

[..]

In ieder geval geen snapshots, dat heeft EXT4 niet.

Gebruik je een GUI op je server?
Nope, alles gaat commandline! Hoezo wou je dat weten?
Verveel je je? Check dan deze site!
  dinsdag 2 januari 2018 @ 18:15:06 #7
312852 Stratocruiser
Klootzak-engineer from NASA
pi_176241320
registreer om deze reclame te verbergen
quote:
0s.gif Op dinsdag 2 januari 2018 18:10 schreef Claude_Viole het volgende:

[..]

Nope, alles gaat commandline! Hoezo wou je dat weten?
Eigenlijk wat ver gezocht, zat te denken aan de prullenbak (~/.local/share/Trash) waar files in staan. Worden die logs dmv een script verwijderd?
  dinsdag 2 januari 2018 @ 18:17:15 #8
418311 Claude_Viole
Loopt te kloten...
pi_176241357
quote:
0s.gif Op dinsdag 2 januari 2018 18:15 schreef Stratocruiser het volgende:

[..]

Eigenlijk wat ver gezocht, zat te denken aan de prullenbak (~/.local/share/Trash) waar files in staan. Worden die logs dmv een script verwijderd?
Jep, dat klopt! Ze roteren namelijk! ;)
Verveel je je? Check dan deze site!
pi_176241540
Heb je al een fsck gedaan?
  dinsdag 2 januari 2018 @ 18:34:15 #10
418311 Claude_Viole
Loopt te kloten...
pi_176241661
quote:
0s.gif Op dinsdag 2 januari 2018 18:28 schreef Farenji het volgende:
Heb je al een fsck gedaan?
Ik zal eens kijken, hoe kan ik dit het beste runnen? nog met bepaalde parameters?

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 ]
Verveel je je? Check dan deze site!
pi_176242560
Je kan de home partitie unmounten en dan fsck erop runnen, maar dat is misschien onpraktisch, je kan beter een fsck na reboot forceren met

sudo touch /forcefsck
sudo reboot

Dat kan ff duren maar je server komt daarna vanzelf wel terug.
  dinsdag 2 januari 2018 @ 19:18:39 #12
418311 Claude_Viole
Loopt te kloten...
pi_176242920
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 :P?
Verveel je je? Check dan deze site!
pi_176243263
quote:
0s.gif Op dinsdag 2 januari 2018 19:18 schreef Claude_Viole het volgende:
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 :P?
Nee geen uur, denk eerder in minuten. En ja dat bestand wordt gewoon gewist.
  dinsdag 2 januari 2018 @ 19:35:03 #14
418311 Claude_Viole
Loopt te kloten...
pi_176243341
Maar dan ben ik enkel nog benieuwd naar de reden waarom die waarde zo gigantisch fout is.
Verveel je je? Check dan deze site!
pi_176248229
quote:
0s.gif Op dinsdag 2 januari 2018 19:35 schreef Claude_Viole het volgende:
Maar dan ben ik enkel nog benieuwd naar de reden waarom die waarde zo gigantisch fout is.
Weet ik ook niet, paar geflipte bitjes ofzo?
  woensdag 3 januari 2018 @ 15:16:35 #16
418311 Claude_Viole
Loopt te kloten...
pi_176260118
Apart.... toch lees ik regelmatig dat dit gebeurt.

Ik ga sowieso komende week die logging wat temmen dat hij minder gaat schrijven. Hij logt iets teveel crap zie ik ;).
Verveel je je? Check dan deze site!
  woensdag 3 januari 2018 @ 16:52:54 #17
23339 Henno
!!!!!1111heinz11!!
pi_176262436
In mijn Linux tijd was mijn ervaring met de ext filesystems nog weleens dat als je een bestand verwijderde waarop nog file descriptors open stonden, de ruimte pas vrijgegeven werd als deze descriptors gesloten werden (bv. door een daemon te herstarten o.i.d.). du zag t dan niet meer (want de bestanden waren er niet meer), maar df zag het nog wel als gebruikt.

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 :P

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 :P

[ Bericht 15% gewijzigd door Henno op 03-01-2018 17:11:00 ]
  woensdag 3 januari 2018 @ 22:17:12 #18
418311 Claude_Viole
Loopt te kloten...
pi_176270413
Ga ik ook maar eens bekijken. Het is in ieder geval een geavanceerd pythonscript.
Verveel je je? Check dan deze site!
  donderdag 4 januari 2018 @ 00:07:50 #19
418311 Claude_Viole
Loopt te kloten...
pi_176272297
Net even het script gekilled, en een nieuwe dh -lh gedaan.
Opeens had ik de ruimte weer terug. van de week maar eens even het script temmen omdat hij een hoop bullshit logt.
Verveel je je? Check dan deze site!
pi_176274400
Het ‘probleem’ is dus dat een rm commando in Linux niet geheel direct een bestand verwijderd.
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.
  donderdag 4 januari 2018 @ 15:44:57 #21
2671 Aaargh!
Gebruik op eigen risico.
pi_176282602
quote:
0s.gif Op dinsdag 2 januari 2018 12:24 schreef Claude_Viole het volgende:
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?
Ja, dat kan heel goed.

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:
1lsof -nP +L1
It is impossible to live a pleasant life without living wisely and well and justly.
And it is impossible to live wisely and well and justly without living a pleasant life.
  donderdag 4 januari 2018 @ 21:23:31 #22
418311 Claude_Viole
Loopt te kloten...
pi_176289629
Ik zal de maker eens vragen of hij dit kan aanpassen aan het script.

Inmiddels is de logging nu getemd in de nieuwe update. :)
Verveel je je? Check dan deze site!
abonnementen ibood.com bol.com Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')