Onderwerp: Ubuntu server crashes

Vanmorgen vroeg en maandag avond laat is een van mijn Ubuntu servers gecrashed.

Er hangt geen beeldscherm aan en een collega heeft ze uit en aan gezet omdat ik zelf niet in de buurt was.

In de syslogs is niets terug te zien, er zijn geen meldingen na een bepaalde tijd, tot de server uit en aan gezet is.

Het enige wat ik kan vinden is dat de /boot vol zit.
Kan dat een oorzaak zijn dat de machine crashed?

Out of Memory is de meest voorkomende oorzaak. Onderstaande in je sysctl.conf zetten kan soms (niet altijd) uitkomst bieden door een automatische herstart:

Code:

# Auto-reboot linux 30 seconds after a kernel panic
kernel.panic = 30
kernel.panic_on_oops = 30

Voeg dit eraan toe om te voorkomen dat je geheugen overboekt wordt:

Code:

# No overcommitment of available memory
vm.overcommit_memory = 0

En is het een VM dan wil je zo min mogelijk swappen wanneer je SAN/NAS gebruikt (traag):

Code:

# Do less swapping
vm.swappiness = 10

Elke partitie die vol zit kan een crash veroorzaken, puur afhankelijk van welke processen ernaar moeten schrijven.
Nu zou dat bij /boot niet moeten voorkomen, maar wellicht heb je ergens logs/crashdumps/coredumps die erin terecht komen?

Oorspronkelijk geplaatst door systemdeveloper

Elke partitie die vol zit kan een crash veroorzaken, puur afhankelijk van welke processen ernaar moeten schrijven.
Nu zou dat bij /boot niet moeten voorkomen, maar wellicht heb je ergens logs/crashdumps/coredumps die erin terecht komen?

Een volle partitie hoeft niet gelijk een crash te veroorzaken. Vaak is er een reservering specifiek voor log files etc etc.

Oorspronkelijk geplaatst door Mikey

Een volle partitie hoeft niet gelijk een crash te veroorzaken. Vaak is er een reservering specifiek voor log files etc etc.

Hoeft niet inderdaad, maar die 5-10% reserve op /boot (vat vaak sowieso al klein is) is in de praktijk nu ook weer niet zo gek veel.

Maar wordt er bij een kernel panic niets in het syslog weggeschreven? Ik heb de reboot actie in ieder geval toegevoegd, bedankt daarvoor.

Het is geen VM overigens, hij wordt wel gestart van een SSD dus minder schrijfacties kan een voordeel zijn.
Werken de VM. opties ook bij een niet VM?

Er staan ook geen logfiles in /boot, alleen Grub en een berg oude kernel images. Ik heb een aantal oude versies verwijdert en via apt-get autoremove de rest opgeschoond. Er is nu weer meer dan voldoende ruimte vrij. (autoremove werkte eerst niet ivm 0 bytes vrij)

VM staat voor virtual memory, niet voor virtual machine

Hoi,

Een volle /boot partitie zal nooit een crash kunnen veroorzaken. Ook is de Out of Memory post een beetje onzin. De kernel bevat een OOM Killer. Deze zal een PID (Process ID) killen als het systeem volledig zonder geheugen meer zit. Je ziet dan in de syslog meestal staan: Out of Memory: Killed process [PID] [process name].

Ik zou als dit vaker gebeurt een kernel dump laten maken als de server crashed / kernel panic'ed.

Het kan best zijn dat je SSD uit je systeem gedropped is en dat ie daardoor gecrashed is, hebben onze dozen met SSD's ook af en toe last van. Je zal daar niets van terug zien in logs omdat je systeem gewoon compleet weg is.

Oorspronkelijk geplaatst door Paulewk

Het kan best zijn dat je SSD uit je systeem gedropped is en dat ie daardoor gecrashed is, hebben onze dozen met SSD's ook af en toe last van. Je zal daar niets van terug zien in logs omdat je systeem gewoon compleet weg is.

Als je SSD eruit vliegt, kan hij er ook geen logs naar schrijven :P

Oorspronkelijk geplaatst door RobinBoorsma

Als je SSD eruit vliegt, kan hij er ook geen logs naar schrijven :P

Wat goed van je, je zegt precies hetzelfde als de post die je quote .

Oorspronkelijk geplaatst door Paulewk

Wat goed van je, je zegt precies hetzelfde als de post die je quote .

Weet ik, ik houd van herhalen voor de tragen onder ons, daarom typ ik ook slomer zodat ze het rustig kunnen lezen

Wel goede tips van Randy

Laatst had ik een server waarvan de schijf corrupt is geworden, de schijf werd toen Read-only gezet (door het systeem?) waardoor vele processen vast liepen en crashten.
Na een herstart en een fsck draaide alles weer super. Misschien dat hier iets gelijkaardigs gebeurde? Ook geen logs van (want het systeem werd read-only), al kwam de server niet online na een normale herstart, maar na het manueel uitvoeren van fsck in resque-modus (Debian). Overigens een Virtuele server.

Oorspronkelijk geplaatst door RobinBoorsma

Als je SSD eruit vliegt, kan hij er ook geen logs naar schrijven :P

Daarom hebben ze ook remote syslog servers uitgevonden, zodat je logs nog extern weggeschreven worden ook al staat je file system in read only of is je schijf volledig weg.

Oorspronkelijk geplaatst door JelleDL

Wel goede tips van Randy

Laatst had ik een server waarvan de schijf corrupt is geworden, de schijf werd toen Read-only gezet (door het systeem?) waardoor vele processen vast liepen en crashten.
Na een herstart en een fsck draaide alles weer super. Misschien dat hier iets gelijkaardigs gebeurde? Ook geen logs van (want het systeem werd read-only), al kwam de server niet online na een normale herstart, maar na het manueel uitvoeren van fsck in resque-modus (Debian). Overigens een Virtuele server.

Ruikt naar een onderliggend storage probleem. Was dit op eigen hardware of via een VPS provider?