[nicht gelöst] ld.so -> macht probleme

[pagaty]

hi,

mein server macht mir grad en wenig sorgen.

es fing an, das ich mich nicht mehr per ssh einloggen konnte. erst mal panik bekommen, da ich dachte evtl. gehackt und n rootkit drauf oder sowas.

fehlermeldung beim login:

Code: Alles auswählen

chab@wichtolino:~$ ssh rs
chab@rs's password: 
Linux <rechnername> 2.6.18-3-686-bigmem #1 SMP Mon Dec 4 18:07:02 UTC 2006 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
Last login: Mon Mar 17 08:23:36 2008 from p5b0ac088.dip.t-dialin.net
Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 657: elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8' failed!
Connection to rs closed.

dann habe eine reboot im rescuesystem (hetzner) gemacht und erst mal rkhunter und chkrootkit laufen lassen. zum glück nichts gefunden (puh)(schwitz).

nach erneutem reboot gings dann. habe dann die logs mal überflogen, und nur gesehen, das die authentifizierung fehlgeschlagen ist. syslog war leider von iptables so vollgemüllt, das eine auswertung nichts ergab (habe ich schon geändert).

jetzt ist es so, das ich alle 5-7 tage neu booten muss, um mich anmelden zu können.

beim durchsuchen der logs taucht immerwieder dieser fehler auf. hier z.b. von rkhunter

Code: Alles auswählen

* Check: Events and Logging
   Search for syslog configuration...                         [ OK ]
   Checking for running syslog slave... Inconsistency detected by ld.so: ../sysd
eps/i386/dl-machine.h: 657: elf_machine_rel_relative: Assertion `((reloc->r_info
) & 0xff) == 8' failed!
                      [ Warning! ]
    Info: Cannot find syslog/syslog-ng daemon

dieser teil taucht auch ständig im log auf

Code: Alles auswählen

Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 657: elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8' failed!

jetzt habe ich erst mal bedenken an der ld.so herumzuexperimenieren, bevor ich nicht weis wo der fehler ist.

über denkanstöße bin ich dankbar.

lg
pagaty

[Saxman]

Schon mal an kaputte Hardware gedacht?

[pagaty]

der rechenr wurde vor einem jahr überprüft, aber ich wollte erst mal herausfinden, was mit meinem server grad passiert, bevor ich die hetznerjungs losjage.

ich möchte halt erst ausschließen das es "an mir" liegt.

habe die meldung natürlich schon länger gegoogled, aber einen hinweis auf hardware habe ich noch nicht gefunden.

in welche richtung meist du denn soll ich hardwaremäßig auf die suche gehen?
(der ram war vor ca. nem jahr kaput und wurde gewechselt)

ld.so hat doch was mit den shared libarys zu tun. elf ist scheinbar dessen binärformat.
wie gesagt, ich weis noch nicht woher diese "Inconsistency" kommt. ich hätte jetzt in richtung aptitude getippt, das evtl. irgendwelche libarys "falsche" versionsnummern haben. aber ich habe die letzte zeit nichts am server gemacht.


lg
pagaty

[Saxman]

Ich hätte jetzt primär auf den speicher getippt wenn an verschiedenen Stellen nicht reproduzierbare Fehler auftauchen. Zweiter Tip wäre die festplatte, da hab Ich auch schon die komischten Sachen erlebt bevor(!!) sie richtig kapputt gegangen sind.

Ich lass mich nicht darauf festnageln aber die ld.so libs sind doch Bestandteil der libc6. Und bevor Ich an einen Fehler in der libc denke, denke Ich eher an Hardware.

[gms]

ld.so hat doch was mit den shared libarys zu tun. elf ist scheinbar dessen binärformat.

ja, das ist der Dynamic Loader, mit dessen Hilfe die Programme bzw die benötigten Shared Libraries geladen werden. Tritt diese Meldung erst am Ende des 5-7 Tage Intervalls oder auch am Anfang ?

Gruß
gms

[pagaty]

ok. da geb ich dir recht.

ich werde mal ein ticket lösen.

wenn es danach geht weis ich wenigstens warum, und wenn nicht wars nicht die hardware. ist der bessere weg.

danke dir.

werde posten ob die hardware was hat.

lg
pagaty

[pagaty]

@ gms

hab heute früh das letzte mal gebootet. seit dem ist noch nichts aufgetaucht.

pagaty

[Igno]

Schreit nach RAM, wenn's erst nach gewisser Laufzeit auftritt. Ich schätze mal, darauf will gms auch hinaus.

Bzgl. getesteter/ausgewechselter Hardware: Da würde ich mich auf kaum noch was verlassen, was ich nicht selbst getestet hätte. Wir hatten bei unserem Root zwei Plattendefekte innerhalb von einer Woche. Die ausgetauschte war offensichtlich schon beim Einbau angeknackst

[pagaty]

hi,

habe eben per aptiude alle aktualisierbaren packte aktualisiert.

da kam dann bei

Code: Alles auswählen

Richte nfs-common ein (1.0.10-6+etch.1) ...
Stopping NFS common utilities:Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 657: elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8' failed!
 statd.
Starting NFS common utilities: statd.

wie saxman schon vermutet hat ist ist es scheinbar nicht reproduzierbar. zumindest nicht für mich . es ist jedesmal bei nem anderen dienst.

lg
pagaty

[gms]

Wenn das eher erst am Ende des Intervalls auftritt, dann ist es auch eher "wahrscheinlich", daß die Logmeldungen mit den Abstürzen in Zusammenhang stehen.
Das hieße aber, daß der Loader durch äußere Einflüsse aus der Bahn geworfen wird. Ein Hardwaredefekt ( Speicher, Harddisk ) ist daher sicherlich eine Möglichkeit, ein Fehler im Speichermanagement des Kernels auch ( allerdings eher unwahrscheinlich wenn du einen Standardkernel verwendest ), vielleicht aber auch ein Speicherleck in einem Prozeß.
Den Speicherverbrauch würde ich daher auch im Auge behalten, vielleicht läßt sich den Logs auch entnehmen, von welchem Prozeß diese Fehlermeldungen kommen.

Gruß
gms

[pagaty]

was mir allerdings zu denken gibt, ist dass er immer die selbe meldung ausgibt.

wenn er was mit dem ram hätte, müsste er dann nicht willkürlich meldungen ausgeben?

oder meinst du das die platte an der stelle, an der ld.so sitzt ne macke hat?

lg
pagaty

[gms]

wenn er was mit dem ram hätte, müsste er dann nicht willkürlich meldungen ausgeben?

deshalb wollte ich noch andere Alternativen einbringen, ohne mich zuweit vorzuwagen

der meinst du das die platte an der stelle, an der ld.so sitzt ne macke hat?

dort wo der ld.so sitzt sicherlich nicht, es könnte aber auch ein kaputtes Elf-Image ( Programm oder Library ) sein, das müßte dann aber ein reproduzierbares Problem sein

[pagaty]

hi,

top geht grad nicht. wow und das schon nach nem tag!

Code: Alles auswählen

:/var/log# top
Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 657: elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8' failed!

hmmm.....

lg
pagaty

[pagaty]

nachdem ich vom server "gekickt" wurde, und neu gestartet habe, komme ich wieder drauf, und top geht auch.

werde die logs nochmal duchforsten, und hoffe, das ich eine auffälligkeit finde, bei welchem dienst mein fehler am häufigsten auftritt.

lg
pagaty

[Igno]

Das könnte wieder ein Symptom für RAM sein, weil aptitude meines Wissens ja die Paketdatenbank beim Ausführen in den Speicher lädt. Irgendwann kommt er im laufenden Betrieb an die Stelle, wo die Inkonsistenz vorliegt, dann fliegt der Fehler raus. Ich würde grundsätzlich mal in den Rescue-Mode booten und Platte und, wenn möglich, RAM checken. Wenn da keine Fehler auftauchen, wäre das wenigstens ausgeschlossen. Wobei ich es für ziemlich wahrscheinlich halte, dass es am RAM hängt.

[gms]

weil aptitude meines Wissens ja die Paketdatenbank beim Ausführen in den Speicher lädt. Irgendwann kommt er im laufenden Betrieb an die Stelle, wo die Inkonsistenz vorliegt, dann fliegt der Fehler raus.

nach dem das gleiche Programm "top" einmal geht und einmal nicht, bin ich jetzt auch eher auf der RAM Schiene, wieso da aber "aptitude" seine Finger im Spiel haben soll, kapiere ich jetzt nicht so ganz

Gruß
gms

[pagaty]

hi,

werde beides mal im auge behalten.

1. morgen hetzner bescheid sagen
2. logs auswendig lernen

danke erst mal.

werde mich bei neuen infos melden.


lg
pagaty

[Igno]

@gms: Naja, je schneller der Speicher gefüllt wird, desto schneller kommt man an die Stelle, die defekt ist. Wenn aptitude also kräftig in den Speicher schreibt (bei Upgrades schätze ich mal, dass da noch mehr geschrieben wird), landet er schneller an der defekten Stelle, als beispielsweise im ganz normalen Tagesgeschäft.

[gms]

@gms: Naja, je schneller der Speicher gefüllt wird, desto schneller kommt man an die Stelle, die defekt ist. Wenn aptitude also kräftig in den Speicher schreibt (bei Upgrades schätze ich mal, dass da noch mehr geschrieben wird), landet er schneller an der defekten Stelle, als beispielsweise im ganz normalen Tagesgeschäft.

ist nicht so wichtig, aber Ich hätte "pagaty" so verstanden, daß er in den letzten Tagen nichts installiert hat

[cosmac]

hi,

"reproduzierbar" ist ja auch relativ... aber wenn z.B. "top" nicht
geht, geht es garnicht mehr bis zum Reboot. Wenn dann z.B.
"ping" auch nicht mehr geht, kann man evt. mit "strace top" und
"strace ping" was sehen, nämlich ob es an einer bestimmten
lib liegt. Oder mit ldd nach einer gemeinsamen lib suchen.

Eine andere Erklärung: ld.so, LD_LIBRARY_PATH und Freunde zu
zu manipulieren ist sicher eine gute Grundlage für ein Rootkit,
und wenn das noch nicht ganz ausgereift ist, passiert sowas...

[pagaty]

hi,

eine gute Grundlage für ein Rootkit,

das war auch mein erster gedanke, aber weder rkhunter noch chkrootkit haben was gefunden, auch habe ich keinen traffic der aussergewöhnlich wäre.

meinst du man kann sich auf rkhunter &co nicht verlassen?

lg
pagaty

[pagaty]

huiuijui,

war scheinbar doch die hardware. wollte eben mein ticket lösen, da hat sich der server verabschiedet.

er ist aus.

lg
pagaty

[pagaty]

hi,

habe vorgestern den rechner von hetzner überprüfen lassen. angeblich ist alles in ordnung. weshalb er sich aufgehängt hat, kann ich mir noch nicht erklären.

in syslog und messages war nichts zu sehen. (mir fiel nicht ungewöhnliches auf)

auch die meldung taucht nicht mehr auf.

allerdings ist es so, das ich mich nach 2 tagen schon wieder nicht anmelden kann.

neustart, dann gehts.


kann sich das einer erklären?


lg
pagaty

[pagaty]

hallo,

nur so zur info.

konnte mein problem beheben.

mir fiel auf, das in der auth.log pro sec. ca. 30 abgewiesene anmeldeversuche waren, hab ich den port für ssh geändert.

seitdem habe ich keine probleme mehr. es läuft wie geschmiert. werde wohl meine iptables mal genauer untersuchen müssen, da diese sowas eigendlich abfangen sollte.

lg
pagaty

[pagaty]

hallo,


leider doch nicht gelöst.

Code: Alles auswählen

Last login: Fri Mar 21 23:26:12 2008 from p5b0aef92.dip.t-dialin.net
Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 657: elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8' failed!
Connection to rs closed.

hat jemand nen vorschlag wie ich das problem beheben könnte?

danke im voraus

pagaty