22

Frage an die Linux-Auskenner

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+0x60f/0x7bc
Jan 5 14:59:29 p15168086 kernel: [] ip_route_input_slow+0x60f/0x7bc
Jan 5 14:59:29 p15168086 kernel: [ip_route_input+329/340] ip_route_input+0x149/0x154
Jan 5 14:59:29 p15168086 kernel: [] ip_route_input+0x149/0x154
Jan 5 14:59:29 p15168086 kernel: [ip_rcv+478/1080] ip_rcv+0x1de/0x438
Jan 5 14:59:29 p15168086 kernel: [] ip_rcv+0x1de/0x438
Jan 5 14:59:29 p15168086 kernel: [netif_receive_skb+337/388] netif_receive_skb+0x151/0x184
Jan 5 14:59:29 p15168086 kernel: [] netif_receive_skb+0x151/0x184
Jan 5 14:59:29 p15168086 kernel: [process_backlog+133/276] process_backlog+0x85/0x114
Jan 5 14:59:29 p15168086 kernel: [] process_backlog+0x85/0x114
Jan 5 14:59:29 p15168086 kernel: [net_rx_action+134/288] net_rx_action+0x86/0x120
Jan 5 14:59:29 p15168086 kernel: [] net_rx_action+0x86/0x120
Jan 5 14:59:29 p15168086 kernel: [__do_softirq+78/164] __do_softirq+0x4e/0xa4
Jan 5 14:59:29 p15168086 kernel: [] __do_softirq+0x4e/0xa4
Jan 5 14:59:29 p15168086 kernel: [do_softirq+40/48] do_softirq+0x28/0x30
Jan 5 14:59:29 p15168086 kernel: [] do_softirq+0x28/0x30
Jan 5 14:59:29 p15168086 kernel: [do_IRQ+275/292] do_IRQ+0x113/0x124
Jan 5 14:59:29 p15168086 kernel: [] do_IRQ+0x113/0x124
Jan 5 14:59:29 p15168086 kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20
Jan 5 14:59:29 p15168086 kernel: [] common_interrupt+0x18/0x20
Jan 5 14:59:29 p15168086 kernel: [default_idle+44/52] default_idle+0x2c/0x34
Jan 5 14:59:29 p15168086 kernel: [] default_idle+0x2c/0x34
Jan 5 14:59:29 p15168086 kernel: [cpu_idle+48/64] cpu_idle+0x30/0x40
Jan 5 14:59:29 p15168086 kernel: [] cpu_idle+0x30/0x40
Jan 5 14:59:29 p15168086 kernel: [rest_init+72/76] rest_init+0x48/0x4c
Jan 5 14:59:29 p15168086 kernel: [] rest_init+0x48/0x4c
Jan 5 14:59:29 p15168086 kernel: [start_kernel+361/368] start_kernel+0x169/0x170
Jan 5 14:59:29 p15168086 kernel: [] start_kernel+0x169/0x170

Danke für jede Hilfe!

22 Kommentare

  1. 01

    Den hat Stoibers Bahnhofsrede irritiert. Das war alles. Mehr sagt das da oben nicht.

  2. 02

    Wenn dass so ist, dann weiss ich mit wem Microsoft demnächst einen verflucht hoch dotierten Beratervertag abschliesst.

  3. 03
    steffen

    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.

  4. 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…

  5. 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.

  6. 06
    stb

    was ist das den fuer ne kernelversion?

  7. 07
    Tobi

    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 0x4(%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

  8. 08
    stb

    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?

  9. 09

    Es gab ein paar Versuche sich mit sehr, sehr kruden Benutzernamen via ssh einzuloggen („denise“ z.B.) ansonsten überhaupt _nichts_.

  10. 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 ..

  11. 11
    stb

    die ssh-attacken sind nur ’normales‘ hintergrundrauschen..ich nehm an, dass sie nicht erfolgreich waren und kein login erfolgt ist?

  12. 12
    stb

    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..

  13. 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 ;)

  14. 14

    Ne, erfolgreich waren die Logins nie. Vielleicht wäre es aber dennoch eine Überlegung wert, Login per Passwort zu verbieten.

  15. 15
    stb

    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..;)

  16. 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.

  17. 17

    Das mit dem RAM kann nur unser Hoster überprüfen, die Kiste steht ja nicht bei uns.

    Den Rest verstehe ich nicht. :)

  18. 18

    ich würde mal stark auf bevorstehenden netzwerkkarten bzw. hardware tot tippen.

  19. 19
    Samuel

    find ich cool daß hier keiner _genau_ weiß was Sache ist/war. ;)

  20. 20
    stb

    @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)..

  21. 21
  22. 22
    stb

    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..

Diesen Artikel kommentieren