Wat gebeurt er als /var vol raakt?

[kmf]

Door een stomme fout van mijn kant is mijn /var/ volgeraakt (een extreme logging bij apache aangezet).

Nou kan ik dus niet meer inloggen via ssh, mail, php werkt niet en apache werkt maar voor de helft.

Ik moet nu wachten tot mijn hoster dit opgelost heeft, maar in de tussentijd vind ik het maar vreemd.

Als var vol zit, dan zal al die services toch gewoon moeten door blijven werken? Het is niet zo dat /tmp vol zit? Of zie ik dat nou verkeerd? (ok. er kan niet meer gelogd worden, maar toch....)

[ Voor 6% gewijzigd door kmf op 12-06-2005 19:04 ]

[Zwerver]

Heb je als /var een losse partitie? Of is dat gewoon een map die op je / staat. Want dat zou betekenen dat ook je paar % die vrij gehouden worden voor de superuser vol zijn.

Het kan ook zijn dat je security settings zo staan dat indien er geen inlog attempts weggeschreven kunnen worden (/var/log <<) je niet in mag loggen. Zou wel zo logisch zijn

[SyS_ErroR]

ik heb zelf een keer een paar files gemoved naar /backup ipv /files/backup (/files is een verzameldir van allerlei hdd's die ik in fstab heb aangegeven)

resultaat => MySQL error's, ssh dood, etc, etc, etc

*wijze les* => eerst je cmd controleren, dan pas enter bashen

[kmf]

nee /var heb ik als een aparte partitie gedaan, net zoals /tmp en /

Daarom vind ik het zo vreemd dat er helemaal niks meer gedaan kan worden nu. Het enige wat ik had aangepast voor deze failure was dus die logging aanzetten (en vergeten uit te zetten).
Toen kreeg ik dit soort rotzooi.

Mysql viel uit, toen volgde php, apache kon alleen nog maar statische files laden en wel allen van main ip. ssh inloggen lukt niet meer gelijk connection lost, etc.

[Verwijderd]

Ik had een tijdje terug ook een /var die vol zat; het systeem liep compleet vast (zat in X) en kon na opstarten X en het merendeel van de programma's niet meer uitvoeren.

Gelukkig was dat lokaal dus zo op te lossen, maar het was bij mij dus ook zo dat al draaiende services en applicaties ineens niet (goed) meer werkten.

[stefklep]

Met he comando cd /var && du -shx * kan je precies zien wat er bij jouw zo groot is er mischien er wat aan doen

[Erkens]

stefklep schreef op zondag 12 juni 2005 @ 20:56:
Met he comando cd /var && du -shx * kan je precies zien wat er bij jouw zo groot is er mischien er wat aan doen

moet je wel kunnen inloggen natuurlijk

[RedShift]

Dan is het gedaan met feesten

[ Voor 11% gewijzigd door RedShift op 12-06-2005 21:24 ]

[zordaz]

Als je zelf bij de machine kunt komen (of je dat kunt is me niet helemaal duidelijk), dan zou je de machine met bijv. een Knoppix CD kunnen starten, het volgelopen filesysteem kunnen mounten en daarna opschonen.

Volgelopen filesystems op *nix machines zijn niet leuk en leiden eigenlijk altijd tot grote, onvoorspelbare problemen. Een oplossing kan zijn om voortaan een logical volume manager te gebruiken. Je kunt dan zonder herpartitioneren (tijdelijk) extra schijfruimte aan een filesysteem toevoegen. In professionele omgevingen wordt dit vaak zo gedaan, want het is dan ook heel makkelijk om een nieuwe / extra harde schijf aan een *nix systeem toe te voegen zonder dat je "fysiek" hoeft te herpartitioneren.

[Verwijderd]

athlonkmf schreef op zondag 12 juni 2005 @ 19:04:
Als var vol zit, dan zal al die services toch gewoon moeten door blijven werken? Het is niet zo dat /tmp vol zit? Of zie ik dat nou verkeerd? (ok. er kan niet meer gelogd worden, maar toch....)

Het ZOU door kunnen werken, maar het kan ook blokkeren.
Ik heb systemen gezien die prima doorwerken. Ik heb ook een systeem gezien waarbij dhcpd (de server) iets wilde loggen, dit niet kwijt kon, vervolgens ging staan wachten op I/O en de hele tcp stack mee trok de diepte in.

Je apache kan blocken, je ssh kan blocken, maar het kan ook gevolg zijn van een andere service die vastloopt.

[Sendy]

Misschien is het leuk als je eens een lsof | grep /var doet wanneer je computer het weer doet. Je kan dan goed zien welke processen er allemaal iets op /var open hebben. Misschien moet je sommige software anders configureren, or leer je dat je misschien /var/log op een andere partitie moet zetten.

[Zwerver]

Overigens is het meest waarschijnlijk dat je services via syslog willen loggen, syslog geen schrijfruimte meer heeft en dus er mee kapt en daardoor al je services er mee ophouden

[ecageman]

Als het goed is moet je nog wel kunnen inloggen via de console. Moet je er alleen wel fysiek bij zitten. Overigens is het redelijk verstandig om services die iets minder belangrijk/kritiek zijn, te laten loggen op een appart filesysteem, zeker de services die veel kunnen gaan loggen zoals bijvoorbeeld apache. Deze services kunnen dan dus nooit ervoor zorgen dat je echt kritieke services zoals bijvoorbeeld SSH ermee stoppen omdat ze niet kunnen loggen.

[teigetjuh]

Zwerver schreef op dinsdag 14 juni 2005 @ 11:38:
Overigens is het meest waarschijnlijk dat je services via syslog willen loggen, syslog geen schrijfruimte meer heeft en dus er mee kapt en daardoor al je services er mee ophouden

Helemaal mee eens.... Hier ook een machine gehad waarvan bijzonder weinig meer wou werken omdat /var op 100% stond. Was overigens solaris... Waarschijnlijk heeft elk unix/linux/bsd-systeem hier last van...

[Zwerver]

teigetjuh schreef op woensdag 15 juni 2005 @ 09:01:
[...]


Helemaal mee eens.... Hier ook een machine gehad waarvan bijzonder weinig meer wou werken omdat /var op 100% stond. Was overigens solaris... Waarschijnlijk heeft elk unix/linux/bsd-systeem hier last van...

Het is niet zozeer last als wel veiligheid. Op deze manier voorkom je nl dat in het geval van een volle /var (denk aan een cracker die het voor elkaar krijgt om je apache zover te laten loggen dat /var vol raakt) je geen logs meer krijgt van login failures en crackpogingen Op zich dus juist heel veilig. Normaal wordt er per filesysteem een aantal % voor de superuser overgelaten zodat je FS niet helemaal vol raakt, maar apache wordt meestal initieel gestart door root en die kan dus wel degelijk het volledige FS volgooien:

code:

alfa:~# ps axu  | grep apache
root      1522  0.0  1.2  15308  4736 ?        S    May29   0:00 /usr/sbin/apache
www-data 28762  0.0  1.9  17952  7456 ?        S    Jun14   0:05 /usr/sbin/apache
www-data 28953  0.0  1.9  17980  7488 ?        S    Jun14   0:03 /usr/sbin/apache
www-data 29316  0.0  2.0  18316  7812 ?        S    Jun14   0:03 /usr/sbin/apache
www-data 29595  0.0  1.9  18012  7512 ?        S    Jun14   0:02 /usr/sbin/apache
www-data 22285  0.0  1.9  18088  7572 ?        S    Jun14   0:01 /usr/sbin/apache
www-data 22287  0.0  2.0  18240  7732 ?        S    Jun14   0:01 /usr/sbin/apache
www-data 22288  0.0  1.8  17780  7208 ?        S    Jun14   0:02 /usr/sbin/apache
www-data 22289  0.0  1.9  18008  7504 ?        S    Jun14   0:01 /usr/sbin/apache
www-data 22972  0.0  1.9  18036  7520 ?        S    00:27   0:00 /usr/sbin/apache
root      2306  0.0  0.1   1536   460 pts/1    R+   10:45   0:00 grep apache
alfa:~#

Zie de eerste regel Als ik van het weekend thuis ben zal ik eens proberen om te checken wat er nou exact gebeurd als /var vol raakt door bijv een non-root account, maar als het goed is blijft je systeem wel draaien