[fedora] df geeft heel andere diskusage dan du *

[Verwijderd]

Ik heb een webserver draaien op Fedora. Hier draait een standaard lamp installatie op. Nu loopt de hardeschijf steeds vol tot 80% en vervolgens daalt hij tot 40-50% . Dit lijkt steeds s'avonds te gebeuren. Het meest rare is dat als ik du -sh / doe ik een totale schijf gebruik krijg van 15 G. df geeft dit:

code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              75G   37G   39G  49% /
/dev/sda1              99M   13M   82M  14% /boot
none                 1010M     0 1010M   0% /dev/shm

Ik heb al alle logs nagelopen en niets lijkt dit te kunnen verantwoorden. Weet iemand waarom de hardeschijf zomaar zo kan vol lopen en opeens weer terug gaat naar 40-50%?

Nu weet ik dat sommige server gehacked worden om vervolgens warez te hosten. Neemt du deze dan niet mee in de telling omdat ze van die vage map namen gebruiken? Is er een manier om deze mappen te vinden?

Ook heb ik nmap gedaan om te kijken welke porten open staan. Ik kon geen rare open porten vinden waarvan ik niets weet. Ook heb ik op alle porten geprobeerd te ftp-en (om misschien een pub op te sporen.) maar nergens kreeg ik reactie. (alleen op de ftp poort natuurlijk. Maar hier kan ik niet anoniem inloggen). Kan ik nog op andere manieren kijken of er iets open staat etc?

[Sendy]

du -sh toont alle files op het gehele filesystem (inclusief gemounte partities). df splits het op per filesystem. Je kan eens du -x gebruiken als je mounts niet mee wil laten tellen.

Waarom denk jij dat er iets gekraakt is? Als jij een bestand van enkele gigs schrijft en dit bestand daarna weggooit dan loopt je hardeschijf zomaar vol en daarna gaat -ie weer terug; wat is hier vreemd aan?

[Verwijderd]

Helemaal niets natuurlijk . En dat hoop ik dan ook. Ik vind alleen raar dat er zo een 25 gb opeens wordt gebruikt voor iets waar ik geen weet van heb. En dat dat savonds oploopt tot 40 GB. Dat terwijl ik helemaal niet met zulke grote bestanden werk.

De commando #du -xsh / geeft:
14G /

Ik heb overigens een 10 webservers in beheer, maar dit ben ik nog nooit tegengekomen. Ik heb eens meegemaakt dat een hardeschijf vol liep vanwege te grote logs. Dit keer wil ik het voorzijn .

Overigens werkt deze server (naar mij weten) niet met ontzettend grote logs. De grootste log die ik ben tegengekomen was 1 GB en deze heb ik al geleegd.

Dit commando had ik daarvoor gebruikt:
#find / -type f -size +1000000 –print

Ook zou ik niet weten met welke andere grote bestanden de server werkt. Misschien met backup's maar die zijn ook niet veel groter als 500 MB.

Kan het zo zijn dat er bestanden worden 'unlink'-ed maar deze dus nog eigelijk op de hardeschijf blijven staan? Is dit op een manier definitief te verwijderen?

Overigens heb ik dat gehack nagekeken omdat dat steeds omhoog kwam in de search.

[ Voor 4% gewijzigd door Verwijderd op 16-01-2006 10:52 ]

[BiG_G]

Na, hack zal het niet zijn.
Je kan eventueel kijken wie er allemaal geconnect zijn met je machine: netstat

Wbt logs:
Als je je logrotatie versnelt, en daarbij logsize=<200 mb maakt. Vervolgens een scriptje om je logs ouder dan 2 dagen te deleten....
Scheelt misschien iets (toepassen op alle logs)

Als je het idee hebt dat het alleen 's avonds gebeurt, misschien een idee om cron even te bekijken?

[Sendy]

Ik heb nogal moeite om je leesbare df en du te lezen. Misschien kan je ze in code-blokken plaatsen, dan blijven spaties tenminste bestaan. Als ik het goed heb geeft 36GiB terug en du -xs maar 14GiB.

Ik kan eigenlijk geen reden bedenken hoe dit zo komt. Als er sparse-files zijn zou je dit juist andersom verwachten.

Files die je unlink()t, en die geen extra hardlinks hebben zijn echt helemaal weg. Als ze wel hardlinks hebben blijven de andere hardlinks natuurlijk wel bestaan. Als ik de man page van du goed gelezen hebt telt jouw invocatie deze hardlinks echter niet mee. (En dan weer; de uitslag zou dan precies andersom zijn.)

Ik zou toch eens onderzoeken welke die grote files zijn. Daarna kan je dan uitzoeken van wie deze zijn of door wie deze geschreven worden. Maak dus een scriptje dat na een df (die aangeeft dat er veel ruimte in gebruik is) zo'n find doet. Succes vast.

[Wilke]

Dat de verschillen zo enorm zijn is inderdaad vreemd, dat het verschillend is kan op zich gebeuren, met name als je een enorm grote (log?)file hebt ergens, en deze vervolgens gewist wordt terwijl er nog wel processen bestaan die het bestand geopend hebben. Op dat moment zal 'df' het bestand niet meetellen, maar totdat alle processen dat bestand hebben gesloten, bestaat het nog gewoon op de harddisk en zal du het dus meetellen.

Heb je geen access_log die elke dag enkele GB's wordt, en dat er iets met logrotaten niet goed gaat oid? Vertel eens iets meer over die server - hoeveel hits krijgt hij te verwerken per dag (welke orde van grootte)? Wat voor soort software draait er op? Staan er (per ongeluk?) wat veel debug/logging facilities aan?

In ieder geval lijkt het gebeuren te wijzen op de creatie van grote bestanden die vervolgens gewist worden (zodat df ze niet ziet) maar nog wel open zijn, mogelijk totdat je 's nachts alle daemons automatisch herstart (als je zoiets doet tenminste)...dus daarna is dan alle ruimte ook voor 'du' ineens weer vrij.

[Verwijderd]

* Heb even de df resultaat in code blokken geplaats

Oke, de serverdruk:
Hits per maand: ~ 50.000.000
Dataverkeer: ~ 200 GB per maand

Logrotatie staat op 'daily' . De log van 1 GB die ik heb verwijderd was een error_log. Blijkbaar maakt 1 domain ontzettend veel errors aan. Toch ben ik niet echt onder de indruk van een 1 GB log bestand, maar ik ga kijken of ik deze errors in iedergeval kan verhelpen. Zou het hiermee iets te maken kunnen hebben?..

Wacht eens. Ik heb net httpd herstart en df staat nu op:

code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              75G   14G   62G  18% /
/dev/sda1              99M   13M   82M  14% /boot
none                 1010M     0 1010M   0% /dev/shm

.Toch vreemd. Toch kan het wel kloppen. Als ik apache stop zet, moet ik heb altijd 2x stoppen. Met het backup-en gebeurt dit waarschijnelijk maar 1 keer waardoor apache eigelijk nooit wordt herstart. Dus alle logs blijft hij onthouden en de logs worden te groot.

Ik ga nu even alle logs etc nalopen. Ik denk dat ik er nu uit ga komen. Heb teminste goede hoop


Bedankt voor alle goede en snelle hulp

Nog 1 vraag. Heeft iemand een verklaring waarom ik apache 2x moet stoppen steeds?

------------------------------------------------------------------------------------------------------------------------------
edit:

Het probleem lijkt dus verholpen te zijn. Apache hoef ik nu niet meer 2x te stoppen (wellicht te maken met de te grote error_logs) . Het bleek dat er een script dat elke minuut aangeroepen werd zorgde voor een paar warnings die steeds in de error_log wordt weggeschreven. Script heb ik aangepast en de error_log is gestopt met hevig te groeien. Dit probleem kwam dus door te grote logs en dat apache niet wou herstarten. Ik ga er nu voor zorgen dat er geen php errors meer worden gelogd om dit ook in de toekomst te vermijden.

Nogmaals allemaal bedankt en wat mij betreft mag er een slotje op dit topic.

[ Voor 24% gewijzigd door Verwijderd op 16-01-2006 12:44 ]