Unser Server stand gerade für einige Minuten still (worüber Max per SMS informiert wird, cool, oder?). Hier kommt ein Auszug aus den Logs, kann das jemand enträtseln? Was will uns der Künstler damit sagen?
nel: [ip_route_input_slow+1551/1980] ip_route_input_slow+0×60f/0×7bc
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [ip_route_input+329/340] ip_route_input+0×149/0×154
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [ip_rcv+478/1080] ip_rcv+0×1de/0×438
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [netif_receive_skb+337/388] netif_receive_skb+0×151/0×184
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [process_backlog+133/276] process_backlog+0×85/0×114
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [net_rx_action+134/288] net_rx_action+0×86/0×120
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [__do_softirq+78/164] __do_softirq+0×4e/0xa4
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [do_softirq+40/48] do_softirq+0×28/0×30
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [do_IRQ+275/292] do_IRQ+0×113/0×124
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [common_interrupt+24/32] common_interrupt+0×18/0×20
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [default_idle+44/52] default_idle+0×2c/0×34
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [cpu_idle+48/64] cpu_idle+0×30/0×40
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [rest_init+72/76] rest_init+0×48/0×4c
Jan 5 14:59:29 p15168086 kernel: [
Jan 5 14:59:29 p15168086 kernel: [start_kernel+361/368] start_kernel+0×169/0×170
Jan 5 14:59:29 p15168086 kernel: [
Danke für jede Hilfe!
01
Den hat Stoibers Bahnhofsrede irritiert. Das war alles. Mehr sagt das da oben nicht.
Alle Kommentare von Daniel
02
Wenn dass so ist, dann weiss ich mit wem Microsoft demnächst einen verflucht hoch dotierten Beratervertag abschliesst.
Alle Kommentare von Max
03
Das sieht wie ein Backtrace aus, also die Zurückverfolgung von Funktionsaufrufen, für’s Debugging. Guck mal weiter oben ob da irgendwo ein oops steht. Hast du da irgend welche ungewöhnliche Routing Optionen aktiviert? Daher scheint das nämlich zu kommen eventuell auch von merkwürdigen Firewall-Regeln.
Schick ein Bug-Report an den Distributer wenn es ein Kernel von denen ist.
Ansonsten ist der Kernel jetzt in einem nicht unbedingt definierten Zustand, also leider neu booten wenn niemand genau was damit anzufangen kann. Ja, gibt es auch bei Linux.
Alle Kommentare von steffen
04
ich hab mich eben noch gefragt, wo es einen service gibt, der einen per sms informiert, wenn der server down ist. wir haben nämlich auch gerade stress mit der kiste…
Alle Kommentare von johannes
05
@steffen: Kein oops weit und breit. (Sollte dass nicht sowieso ein “fuck!” sein?) Soweit ich weiss auch keine merkwürdigen Firewall Regeln.
Dass mit dem neu booten mussten wir schon machen um wieder auf die Kiste drauf zu kommen.
@Johannes: Ich habe meien Account bei http://www.serverguard24.de/. Die scheinen mir recht gut zu sein, wobei es auch viele andere gibt.
Alle Kommentare von Max
06
was ist das den fuer ne kernelversion?
Alle Kommentare von stb
07
da über das System nichts Näheres bekannt ist, konnte ich auch nur den Funktionsaufruf in der ersten Zeile verwerten. Vielleicht dient ja der folgende News-Beitrag als guter Ausgangspunkt, um den Fehler einzukreisen:
Good day,
This is an attempt to collect any useful information or similar cases.
Since a few weeks ago, three Linux 2.4.19 PPTP servers running Poptop
(now 1.1.3) have been crashing like crazy. These servers used to be
rock solid for months. Nothing has changed except a slightly
increasing load. This is really giving me headaches, as we use these to
serve a total of ~900 VPN connections 24×7.
[Note for comp.protocols.ppp readers who might not know this: pptp forks
ppp to handle the packets once encapsulation has removed, so it's not
completely off-topic as some could think]
I have been discussing this in the linux-kernel mailing list (see
messages with subject “Frequent/consistent panics in 2.4.19 at
ip_route_input_slow, in_dev_get(dev)”).
Here is a short summary of what has surfaced so far:
- crashes always occur at the same location:
0xc02318a9 : incl 0×4(%edx)
This matches the inline expansion of in_dev_get(dev) at line #1331 of
/usr/src/linux/net/ipv4/route.c (2.4.19 kernel).
- it occurs because %edx (actually the ‘dev’ argument) points to an
interface structure that has been freed by the kernel already, as
enabling kernel slab poisoning has demonstrated.
- reason would be that kernel sees packets coming from a ppp interface
that already has been deleted, which should not be possible
Alexey Kuznetsov, , who co-developed this code,
wrote the following: (my own questions are quoted ‘> ‘)
> I assume that the kernel is trying to use dynamic memory that has been
> released already, right?
Right.
> What’s next in tracing this one down?
To tell what exactly driver makes this. Apparently, it continues
to inject packets to the stack even after it has been destroyed.
If you did not see message “Freeing alive device”, this means
that driver unregistered it. Usual ppp seems to be sane…
> In this case, would they be packets TO or FROM the ppp device?
FROM, of course. When a packet reaches IP, the device is already destroyed.
This is impossible, unless driver is broken or we have an error
in reference counting. The second possibility is eliminated by the fact,
that you do not see “Freeing alive device”. So, device was cleanly
unregistered.
> No such message in logs, but I see frequent “PPPIOCDETACH file->f_count=3″
I will look. It sounds as an interesting hint.
> - pptp (PoPToP). But pptp is only userland software, how could it cause
> such a problem?
In no way.
[hairy iptables config with one rule per connection to do packet
accounting, would packets been delayed and...]
> thus re-injected to the stack later than usual? (I’m probably just
> talking nonsense here - sorry - trying to guess).
It is not a nonsense. However, iptables hold necessary reference
counts.
~~~~~~~~~~~~~~~~~~~~
I’m sending this to the Poptop list and to Paul Mackerras, although
Alexey has ruled out that pptpd could be the direct cause and has said
that no such problems are known with ppp so far. Somehow, it has to be
related anyway, so I’m hoping that someone can provide a clue.
Some extra information:
- the boxes were actually running 2.4.17 and 2.4.18 when they started
crashing, as well as Poptop 1.1.2. They have been updated in the hope
that it would fix things, but it hasn’t made any difference
- after upgrading the kernel to 2.4.19, I’ve had to download and
install ppp-2.4.2b1 (CVS) because the upgrade had broken
something (clients got “loopback detected”). Updating ppp fixed that
(plain re-compile of ppp and pptp hadn’t)
- we don’t use any encryption, actually this VPN stuff is
used to implement a one-way satellite Internet service, much in the
way some ADSL modems work (I think)
- kernel is unmodified, except a small and dumb patch to get up to
500 PPP devices instead of the normal max 100.
*Many* thanks in advance for *any* hint, even wild guesses that you
may provide. These crashes are ruining my life now, management is
getting quite upset and I don’t do much progress :-(
Greets,
_Alain_
HTH
Tobi
Alle Kommentare von Tobi
08
gibts sonst irgendwelche seltsamen (evtl auch vollkommen unrelated erscheineneden) log-eintraege? hat sich die maschine evtl vorher schon manchmal ’seltsam’ verhalten? sind RAM (ECC?) und festplatten ok?
Alle Kommentare von stb
09
Es gab ein paar Versuche sich mit sehr, sehr kruden Benutzernamen via ssh einzuloggen (”denise” z.B.) ansonsten überhaupt _nichts_.
Alle Kommentare von Max
10
Das mit den Benutzernamen ist eigentlich nichts ungewoehnliches. Ansonsten wuerd ich noch dazu raten den Hostnamen aus dem Log herauszunehmen, wer weiss, was damit so angestellt wird ..
Alle Kommentare von phil
11
die ssh-attacken sind nur ‘normales’ hintergrundrauschen..ich nehm an, dass sie nicht erfolgreich waren und kein login erfolgt ist?
Alle Kommentare von stb
12
wenn der kenrel einigermassen up-2-date ist (zb nicht jener oben erwaehnte 2.4.19) wuerd ich - falls moeglich - mal das RAM mit memtest86+ (http://www.memtest.org/, nicht verwechseln mit dem nicht mehr maintainten memtest86 auf http://www.memtest86.com/) einem stress-test unterziehen. ich hatte schon oefters das ein defektes speichermodul mir sporadisch den kernel crashen lies, einmal sogar mit korrupten userdaten auf der festplatte..sehr unfein..
allerdings dauert der test recht lange und der server ist deshalb fuer einige stunden offline..
Alle Kommentare von stb
13
SMS bekommt man wenn der Server down ist übrigends nicht nur wenn man Geld bezahlt. Bei WebWatch4U bekommt man das Zeugs gratis (15 SMS pro Monat gratis), natürlich nicht mit soo viel Funktionsumfang.
Wie die das finanzieren weiss ich allerdings auch nicht, somit muss man damit rechnen das der Dienst irgendwann mal weg ist. Bis jetzt kam auf jeden Fall keine Rechnung bei mir an ;)
Alle Kommentare von HaiPunk
14
Ne, erfolgreich waren die Logins nie. Vielleicht wäre es aber dennoch eine Überlegung wert, Login per Passwort zu verbieten.
Alle Kommentare von Max
15
oder den sshd auf nen anderen port verlegen. bisher vesuchen es die kiddies nur auf port 22. angenehmer nebeneffekt: weniger muell in den logfiles, dann macht das logfile-lesen wieder richtig spass..;)
Alle Kommentare von stb
16
Nicht das ich solche Fehler bereits gesehen hätte, aber wenn Linux Server abstürzen bzw. einfach nicht mehr ‘ansprechbar’ sind, dann prüfe ich zwei Dinge:
1. Hat der verwendete Kernel bekannte Bugs? Wird aufgrund von Bugs das Upgraden empfohlen (so z.B. bei älteren 2.4 Kernels)
2. Ist der RAM fehlerfrei?
95% der Serverabstürze die sich so ähnlich verhielten ließen auf defekten RAM schließen. Nach einem Tausch war alles i.O.
Alle Kommentare von PatrickU
17
Das mit dem RAM kann nur unser Hoster überprüfen, die Kiste steht ja nicht bei uns.
Den Rest verstehe ich nicht. :)
Alle Kommentare von Johnny
18
ich würde mal stark auf bevorstehenden netzwerkkarten bzw. hardware tot tippen.
Alle Kommentare von Stefan
19
find ich cool daß hier keiner _genau_ weiß was Sache ist/war. ;)
Alle Kommentare von Samuel
20
@samuel: ferndiagnosen ohne zugriff auf OS und hardware und ohne irgendwelche hintergrundinformation sind offensichtlicherweise niemals ‘_genau_’. wenn du deinem kfz-mechaniker am telefon nur sagst ‘mein auto springt nicht an’ wird er dir wohl auch kaum sagen koennen, wo das problem liegt..
die verwendete kernel-version waere schon recht hilfreich (’uname -a’ in der shell)..
Alle Kommentare von stb
21
2.6.7-040722
Alle Kommentare von Johnny
22
hmm, es wurden nach 2.6.7 aenderungen an ip_route_input_slow gemacht - aber ob das was mit dem crash hier zu tun hat ist fraglich. ich wuerde ein kernel-update machen und wenn es dann immer noch probleme gibt das RAM testen bzw gleich austauschen lassen - insb wenn der naechste crash komplett andere fehlermeldungen verursacht..
Alle Kommentare von stb