Welches Paket liefert /lib/ld.so ? - Inconsistency detected

[ssh-agent]

Hallo Leute!

Aus welchem Paket stammt eigentlich die Datei /lib/ld.so?

Eine Durchsuchung der Apt-Liste mit

Code: Alles auswählen

grep "ld.so" /var/lib/dpkg/info/*.list

brachte als Antwort nur

Code: Alles auswählen

/var/lib/dpkg/info/libc6.list:/usr/share/man/man8/ld.so.8.gz

Hintergrund ist, dass ich die Ursache für folgende häufiger eintrudelnden Fehlermeldungen zu klären versuche:

Code: Alles auswählen

Inconsistency detected by ld.so: rtld.c: 925: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!

[Joghurt]

libc6

[ssh-agent]

Davon bin ich eigentlich auch ausgegangen, aber ein

Code: Alles auswählen

dpkg -L libc6

zeigt nichts von einer /lib/ld.so an. Lediglich eine ld-2.3.2.so wird aufgelistet.

Tatsächlich habe ich in /lib aber eine Datei ld.so, die kein Symlink auf ld-2.3.2.so ist:

-rwxr-xr-x 1 root root 99568 Mar 7 2001 ld.so

Auf einem zweiten Rechner mit Debian Sarge, der natürlich ebenfalls das Paket libc6 beinhaltet, existiert diese Datei komischerweise nicht.

Sehr seltsam!

[KBDCALLS]

Was ergibt

Code: Alles auswählen

dlocate /lib/ld.so

eventuell mußt du das Paket

Code: Alles auswählen

dlocate

installieren

[gms]

/lib/ld.so und /lib/ld-linux.so sind die "dynamic linker", wie die genau installiert werden, bin ich jetzt auf die schnelle auch nicht draufgekommen. Beide melden sich jedoch mit "ld.so" obwohl der erste (ld.so) für a.out und der zweite (ld-linux.so) für ELF zuständig ist.
Vermutlich wird deine Fehlermeldung also vom ld-linux.so stammen.

Code: Alles auswählen

root:~# /lib/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we can handle
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                        in LIST

Code: Alles auswählen

root:~# /lib/ld.so
/lib/ld.so: invalid dynamic linker option -1073743164

Gruß
gms

[ssh-agent]

Die Ausgabe von dlocate liefert:

Code: Alles auswählen

00:25:43:luna:/lib# dlocate /lib/ld.so
00:25:50:luna:/lib#

Kann ich jetzt davon ausgehen, dass diese Datei eigentlich nichts hier zu suchen hat?

Weitere Merkwürdigkeit: Man beachte das Datum der ld.so (siehe oben) Verdammt alt für ein frisches Sarge! Ich habe die Box nicht selbst installiert, sondern es handelt sich um einen vorinstallierten Root-Server.

Testweise hab ich nun die /lib/ld.so nach /lib/ld.so.old umbenannt... die Kiste startet ohne zu murren und alles scheint bisher rund zu laufen.
Der "Inconsistency-Fehler" trat voher selten und sporadisch, meist unter hoher Last in Verbindung mit Cron-Jobs auf. Daher dachte ich zunächst an einen Festplattendefekt. Fsck hatte aber keine Beanstandungen.

Die Frage, die bleibt: Was hat das komische Ding da verloren?

[Joghurt]

Tatsächlich habe ich in /lib aber eine Datei ld.so, die kein Symlink auf ld-2.3.2.so ist:

Und letztere ist in libc6 drin.

[gms]

Die Frage, die bleibt: Was hat das komische Ding da verloren?

Bei diesem komischen Ding handelt es sich um den "a.out Dynamic Linker". Dieser ist für das Laden von Shared Libraries zuständig. Da die meisten Shared Libraries unter Linux im "ELF" Format vorliegen, wird deine Fehlermeldung auch höchst wahrscheinlich nicht vom "a.out Dynamic Linker", sondern vom "ELF Dynamic Linker" (ld-linux.so) kommen.
Das ist auch der Grund, warum du nach der Umbenennung von ld.so keine Auswirkungen spürst. Es wäre aber reiner Zufall, wenn obige Fehlermeldungen jetzt nicht mehr auftreten würde.

Bei der Fehlermeldung handelt es sich um eine Assertion. Aus Sicht des Linkers/Loaders sollte dieser Fehler gar nicht möglich sein und ist daher die Folge eines nicht korrekt behandelten anderen Fehlers. Ein Umstand, der das Auffinden der Fehlerursache nicht gerade erleichtert. Hast du die Logs schon durchforstet, könnte der virtuelle Speicher zu knapp bemessen sein ?

Gruß
gms

[ssh-agent]

Ich hab mir mal diese Datei lokal mit ghex angeschaut. Sie beginnt mit der Sequenz .ELF

In den Klattextbereichen lassen sich viele Strings erkennen. Neben Strings die sich mit dem Laden von Bibliotheken befassen, tauchen auch viele Sequencen auf, die sich auf Netzwerkfunktionen beziehen (NFS?). Aber was der String *nazgul* da soll ist schon drollig. War der Entwickler evtl HdR-Fan?

[ssh-agent]

Ich sollte mir nun doch sorgen machen? http://vil.nai.com/vil/content/v_99497.htm

[TCA]

Ist bei mir das selbe, /lib/ld.so ist vorhanden, der String *nazgul* ebenfalls.

Weiß jetzt auch nicht was ich davon zu halten habe, da bei andren Systemen
ld.so nicht vorhanden ist.

Habe mal clamscan drauf gesetzt, der sagte ok, was ja auch nichts heißt.

Weiß jemand was näheres?

[KBDCALLS]

Wen ich mal ein find im /lib ansetze wird nix gefunden

root@biljana:/lib# find |xargs grep nazgul
grep: ./modules/2.6.12-0-k7/source: Datei oder Verzeichnis nicht gefunden
grep: ./modules/2.6.12-0-k7/build: Datei oder Verzeichnis nicht gefunden
root@biljana:/lib#

[ssh-agent]

Hallo Marc!

Es wäre mal interesant zu wissen ob deine ld.so das gleiche Datum und die gleiche Größe ausweisst. Denn in der Apt-Datenbank finde ich dieses File nicht. Und ein Dateidatum aus dem Jahr 2001 finde ich auch merkwürdig!

Code: Alles auswählen

-rwxr-xr-x  1 root root 99568 Mar  7  2001 ld.so.old

Ist der Rechner auf dem sich deine ld.so befindet selbst installiert, oder hast du dort genau wie ich, ein vorgefertigtes Sarge drauf?

[SubOptimal]

Hi,

also laut http://packages.debian.org gibt es die ld.so in keinem Packet. Wenn sie über das apt System ins System gelangt ist, dann könntest Du mit "dpkg -S ld.so" herausbekommen mit welchem Paket sie installiert wurde.
Alternativ natürlich Rescue System booten und dann nochmal $Virenscanner und rkhunter darauf ansetzen.

SubOptimal

[Joghurt]

Und ein Dateidatum aus dem Jahr 2001 finde ich auch merkwürdig!

Code: Alles auswählen

-rwxr-xr-x  1 root root 99568 Mar  7  2001 ld.so.old

Ich nicht, schließlich endet die Datei auf ".old", ist wohl eine Sicherheitskopie von früher.

[KBDCALLS]

Und ein Dateidatum aus dem Jahr 2001 finde ich auch merkwürdig!

Code: Alles auswählen

-rwxr-xr-x  1 root root 99568 Mar  7  2001 ld.so.old

Ich nicht, schließlich endet die Datei auf ".old", ist wohl eine Sicherheitskopie von früher.

Das hat @ssh-agent geschrieben.

Code: Alles auswählen

Testweise hab ich nun die /lib/ld.so nach /lib/ld.so.old umbenannt... die Kiste startet ohne zu murren und alles scheint bisher rund zu laufen. 

[TCA]

Das genaue Datum kann ich nicht sagen (@work) aber es war auf jedenfalls 2001.

Das Datum war aber das gleiche wie bei ld.so.1.XX.XX o.ä. aus dem Paket ldso.

Mein Installation basiert auf einem ca. 1.5 Jahre alten Woody.

[gms]

Auf meinem Laptop hier ist /lib/ld.so auch noch aus Woodyzeiten drauf (Paket ldso, siehe http://packages.debian.org/oldstable/oldlibs/ldso). DIe letzte Version dieses Pakets war eine Dummyversion und sollte diese Datei entfernen. Wahrscheinlich habe ich aber vorher auf Testing upgegradet. Die Vorgängerversion dieses Pakets kann auch noch gezogen werden. Ich habe dieses Paket bei mir extrahiert und folgenden Test durchgeführt::

Code: Alles auswählen

root:/home/gms/tmp/lib# strings ld.so.1.9.11 | grep nazgul
*nazgul*
root:/home/gms/tmp/lib# diff /lib/ld.so ld.so.1.9.11
root:/home/gms/tmp/lib# ls -l ld.so.1.9.11
-rwxr-xr-x  1 root root 99568 2001-03-07 03:17 ld.so.1.9.11

@ssh-agent
Nochmals, diese Datei ist sicher nicht für deine Fehlermeldung verantwortlich, die stammt von /lib/ld-linux.so.2

Gruß
gms

[TCA]

Habe mir damals, mit der ersten woody-CD, ein Basissytem installiert und dann gleich nach Sid upgegrated.

Hatte auch schon vermutet das es ein überbleibsel von Woody ist.

Macht mich ganz nervös wenn eine Datei auf dem Rechner ist, deren Herkunft
unklar ist.

[ssh-agent]

Ups, ich hatte nicht gesehen dass der Thread schon etwas länger geworden ist.

Jedenfalls finde ich eure Antworten schon mal beruhigend.

@gms
Falls nun das Inconsistency-Problem weiterhin bestehen sollte wüsste ich erst mal nicht weiter. Ich werde das weiter im Auge behalten. Vielleciht hast du ja noch eine Idee?

Vorab schon mal an alle meinen besten Dank für den Support!

[ssh-agent]

gms, du hast Recht behalten!

Gestern Nacht ist's mal wieder passiert! Der gestartete Cron-Job war Logcheck:

Inconsistency detected by ld.so: rtld.c: 925: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!

Leider ist dieses fehlerhafte Verhalten nicht direkt reproduzierbar, da Logcheck ja stündlich läuft und der Fehler nur gelegentlich auftritt.

[Joghurt]

Mal memtest86 (über Nacht) laufen gelassen? Fehler, die nur sporadisch auftreten, sind oft Hardwarefehler. Vielleicht wird auch der Prozzi zu warm?

[gms]

Das sporadische Auftreten läßt schon Hardwarefehler vermuten, was mich allerdings daran iritiert ist, daß immer die gleiche Fehlermeldung auftritt. Das wäre schon ein großer Zufall, wenn ein Speicherfehler immer nur beim Laden von Shared Librarries auftritt und sonst alles stabil lauft. Gibt es sonst keine Auffälligkeiten ?
Logcheck ist ein Shellscript, welches wiederum Perl und Python-Programme aufruft, ich werde mir das einmal genauer anschauen, es kann durchaus sein, daß einzelne Teile nur zu gewissen Anlässen aufgerufen werden und dadurch ein sporadischer Fehler ausgelöst wird. Weißt du noch bei welchen anderern Cronjobs dieser Fehler auch aufgetreten ist ?

Gruß
gms

[ssh-agent]

Memtest habe ich noch nicht versucht. Defektes RAM würde sich vermutlich auch durch plötzliche Programmabbrüche mit dem Vermerk "Speicherzugriffsfehler" bemerkbar machen. Bis auf die gelegentlich eintrudelnden Fehlermeldungen aus den Cron-Jobs sind mir noch keine weiteren Probleme aufgefallen. Ich hab mal die letzten meldeungen rausgesucht:

28 Jul 2005 06:25:02 Cron <root@luna> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
15 Aug 2005 04:02:08 Cron <logcheck@luna> if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
16 Aug 2005 18:02:02 Cron <logcheck@luna> if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
17 Aug 2005 12:02:05 Cron <logcheck@luna> if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
20 Aug 2005 04:02:08 Cron <logcheck@luna> if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi