rrdtool symbol lookup error

This forum was archived to /woltlab and is now in read-only mode.
  • Seit dem letzten Upgrade spinnen die rrdtools beim anzeigen der Graphen:


    Code
    1. ERROR: STDERR => /usr/bin/rrdtool: symbol lookup error: /usr/local/lib/libpangoft2-1.0.so.0: undefind symbol: g_mutex_trylock


    Habe schon ein


    Code
    1. aptitude reinstall libpango1.0-0


    und ein "Neubau" aus den Quellen


    Code
    1. ./configure
    2. make
    3. make install
    4. ldconfig


    probiert - ohne Erfolg.


    System: Ubuntu 12.04.5 LTS
    Kernel: 3.13.0-52-generic


    Hat jemand einen Tipp ?


    VG Michael

  • Wegen der Abhängigkeiten vielleicht ?



    Ohne funktionierende libpango keine Graphen mit Texten :(


    Siehe auch HIER!


    VG Michael

  • Eher die Frage warum das rrdtool neu gebaut wurde in einer funktionierenden Installation? :)
    Hab auch 1-2 12.04 LTS laufen und dort nach Paket Updates dieses Problem noch nicht gehabt.

  • Ich habe nicht die rrdtools neu gebaut, sondern die libpango.
    Auf dem System sind ausschließlich Pakete aus dem off. Ubuntu Repository.
    Das Einzige, was manuell installiert wurde, ist der IBM Tivoli Client.


    Habe schon div. Pakete, die mit rrdtool in Verbindung stehen mit reinstall überinstalliert - ohne Erfolg.
    Auch eine auf dem System neu compilierte libpango führt eben nicht zum Erfolg.
    Laut diesem Thread hilft ein Rebuild das Problem zu lösen.
    Habe es mit 1.28.0, 1.29.1, 1.30.0 und 1.30.1 erfolglos probiert. Bei den neueren muss ich es noch probieren. Da meldet ./configure noch Probleme.


    BTW: Ich habe 12.04.5 LTS


    VG Michael

  • Und was hat das nun mit PNP4NAGIOS zu tun?


    Weil ich nagios benutzte.
    Weil ich PNP4NAGIOS benutzte.
    Weil PNP4NAGIOS die rrdtools benutzt.
    Und weil rrdtool die libpango benutzt.


    Und hier ist doch das Monitoring Portal, oder ? Hier stellt man doch Fragen zu Nagios, ..., oder ? Und die Graphen, die PNP4NAGIOS erzeugt sind nur noch ROT].


    VG Michael

  • Lieber Michael,


    Du kommst ins Pnp4Nagios Forum und wirfst eine Post ab mit der Überschrift "Bug..."


    Wie es aussieht hast du dir selbst deine rrdtool installation verbockt. Daher meine frage wie dir die pnp4nagios entwickler helfen sollen?

  • Hallo Jörg,


    ich hatte auf dem Monitoring-System bisher nichts "gebastelt". Alle Sachen - mit Ausnahme des TSM Clients - kamen aus den off. Ubuntu-Repositories.
    Anhand der Logs (Apt, unattended-upgrades, ...) lässt sich aber auch nicht mehr nachvollziehen, was das Problem verursacht hat. Mir ist auch nicht sofort aufgefallen, dass die Graphen nicht mehr funktionieren, weil ich da auch nicht jeden Tag hineinsehe (solange es keine Probleme mit irgendwelchen Maschinen gibt, hat man dazu ja auch keine Veranlassung, außer reine Neugierde).
    Nachdem mir das Problem aufgefallen war, hatte ich es natürlich erst einmal mit den üblichen Bordmitteln probiert. Die weitere Recherche hatte dann Hinweise auf "broken dependencies" geliefert, was bei Ubuntu leider ab und an vorkommt. Daher habe ich dann versucht, die libpango (und nur diese) neu zu bauen. Die lässt ich zwar bis hin zur 1.30.X kompilieren und installieren, aber das Problem


    Code
    1. ERROR: STDERR => /usr/bin/rrdtool: symbol lookup error: /usr/local/lib/libpangoft2-1.0.so.0: undefind symbol: g_mutex_trylock


    besteht weiter.
    Die letzte Recherche gestern Abend führte mich zur Glib, aber selbst in der aktuellen Version existiert dort die Funktion g_mutex_trylock. Ich bin also etwas ratlos.


    VG Michael ;(

  • Habe jetzt noch mal alles, was mit pnp4nagios zu tun hat runter geworfen und neu installiert (somit ist alles wieder aus den Ubuntu-Repositories). Ändert nichts außer dem Pfad zur Bibliothek:


    Code
    1. ERROR: STDERR => /usr/bin/rrdtool: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefind symbol: g_mutex_trylock


    Das eigentlich Problem ist wohl nicht die libpango.


    In der Glib ist die Funktion aber definitiv enthalten:


    Code
    1. # nm -D /usr/lib/x86_64-linux-gnu/libglib-2.0.so | grep g_mutex
    2. 0000000000083580 T g_mutex_clear
    3. 000000000001bf20 T g_mutex_free
    4. 0000000000083570 T g_mutex_init
    5. 00000000000835a0 T g_mutex_lock
    6. 000000000001bf40 T g_mutex_new
    7. 0000000000083600 T g_mutex_trylock
    8. 00000000000835d0 T g_mutex_unlock


    VG Michael ;(

  • Solved.


    Der Tivoli hat alles versaut. Ich hatte nicht gesehen, was der alles im Gepäck hatte.



    Löschen der Bibliotheken


    Code
    1. # rm /opt/tivoli/tsm/client/ba/bin/libglib-2.0.so.0
    2. # rm /opt/tivoli/tsm/client/ba/bin/libgmodule-2.0.so.0
    3. # rm /opt/tivoli/tsm/client/ba/bin/libgobject-2.0.so.0
    4. # rm /opt/tivoli/tsm/client/ba/bin/libgthread-2.0.so.0


    Code
    1. # ldconfig


    und alles ist gut. Sogar der TSM Client geht noch:


    Code
    1. # dsmc q b /home
    2. IBM Tivoli Storage Manager
    3. Befehlszeilenschnittstelle des Clients für Sichern/Archivieren
    4. Clientversion 7, Release 1, Stufe 0.3
    5. Client-Datum/Zeit: 07.05.2015 10:31:22
    6. (c) Copyright by IBM Corporation und Andere 1990, 2014. Alle Rechte vorbehalten.


    VG Michael :)

  • Die .deb-Paket muss man sich entweder selbst aus den rpm bauen


    http://wiki.gwdg.de/index.php/…nter_debian_squeeze_64bit
    http://wiki.gwdg.de/index.php/…erver_64-Bit_installieren u.a.


    oder beim neusten 7.1 einfach von der Uni Konstanz herunter laden:


    http://www.rz.uni-konstanz.de/…s/backupsoftware-clients/ (da haben die die Arbeit schon erledigt)


    Im Internet gibt es außerdem ein paar Shell-Skripte, die diese Arbeit automatisiert erledigen (rpm -> deb), da alien die diesem speziellen Fall alleine nicht reicht.


    Den 6.2er habe ich selbst nach dem Muster für Ubuntu gebastelt und auf unsere Ubuntu-Server verteilt und im VMware Server-Template vorinstalliert. Bei allen muss man wohl wegen der Bibliotheken aufpassen (s.o.). Bislang war das bei uns unwichtig, da keine GUI verwendet wurde, aber der Nagios-Server generiert ja mit rrdtool die Graphen und das kann zu den o.g. Problem führen.


    VG Michael :)

  • Die .deb-Paket muss man sich entweder selbst aus den rpm bauen


    Also hast du ein RPM genommen das nicht für dein System bestimmt war/ist und hast daraus ein Debian Paket gebaut ( welches damit noch immer nicht zu deinem System passt )

  • ... welches damit noch immer nicht zu deinem System passt


    Das so gebaute Paket lässt sich problemlos installieren und der TSM Client funktioniert auch. Das Problem an der Art und Weise der Installation nach den o.g. Dokumentationen ist aber, dass an der ldconfig herum geschraubt wird und die Einstellungen somit systemweit gelten. Genau das führt zu dem o.g. Problem mit den Bibliotheken.


    Da ich die GUI des TSM Clients nicht benötige, habe ich die störenden (doppelten) Bibliotheken einfach aus dem Tivoli-Verzeichnis gelöscht. Somit werden jetzt wieder die "richtigen" aus der Distribution benutzt. Wenn man die GUI benutzen wollte, müsste man eine andere Lösung verwenden (User-Profile, Skript, ... what ever).


    VG Michael :)