cups-polld im busy-loop

Falls man in seiner CUPS Konfiguration einen Host permanent abfrägt (BrowsePoll), und CUPS der Version 1.4.x einsetzt, kann es passieren, dass bei länger aussetzender Netzwerkverbindung zum BrowsePoll Zielrechner der cups-polld Prozess in einen busy-loop gerät aus dem der Prozess nicht mehr herauskommt.

Dies kann v.a. auftreten, wenn der CUPS Client sich mit WLAN zum CUPS Server verbindet. Das Fehlverhalten merkt man dann an 100% Auslastung eines CPU-Cores durch cups-polld. Selber konnte ich dass seit längerem auf Mac OS X Clients erleben.
Mac OS X 10.6.8 beinhaltet derzeit CUPS 1.4.7, während Mac OS X Lion CUPS 1.5.x einsetzt, welches ein Bugfix für dieses Problem beinhaltet.

Eine genaue Fehlerbeschreibgung und einen source patch gibt es auf den Bugs Seiten des Debian Projektes
Die Seite wiederum widmet sich aber dem Problem unter Linux – um das Problem auf Mac OS X

  1. reproduzierbar zu machen (und damit testbar)
  2. zu lösen

stellte ich folgende Vorgehensweise auf:

  1. Auf dem Mac OS X Client wird der cups-polld Prozess mangels strace mit der Aktivitätsanzeige beobachtet
  2. Im Normallzustand war der letzte Call von cups-polld:
    _semwait_signal(..)
  3. Auf Linux Seite wird nun die erste Firewallregel geschaltet
    iptables -I OUTPUT 1 -p tcp -d --sport ipp -j REJECT --reject-with tcp-reset
  4. Danach wartet man bis der cups-polld Prozess in die Phase
    recvfrom(...)
    kommt, danach wird auf Linux noch die 2 FW Regel gestartet.
  5. iptables -I INPUT 1 -p tcp -s --dport ipp -j REJECT --reject-with tcp-reset
  6. Danach wird nach ca. 7 Minuten der cups-polld Prozess in den busy-loop übergehen.

Jetzt muss CUPS mit dem auf den Debian Seiten verfügbaren Patch versehen werden. Dazu lädt man derzeit auf den CUPS Seiten die letze 1.4 Version herunter (1.4.8) und patcht diesen. Der Patch beschränkt sich auf die Datei cups/request.c und lautet folgendermassen

+ {
+ status = httpUpdate(http);
+ }
+- while (http->state == HTTP_POST_RECV);
++ while (status != HTTP_ERROR && http->state == HTTP_POST_RECV);
+
+ DEBUG_printf(("2cupsGetResponse: status=%d", status));
+

Beim anschliessenden kompilieren unter Mac OS X ist natürlich die Entwicklungsumgebung notwendig, zumindest die gcc toolchain auf der Kommandozeile. Folgende Schritte sind notwendig:

  • ./configure CFLAGS=“-arch i386 -arch x86_64″ LDFLAGS=“-arch i386 -arch x86_64″

    Dies führt zum Kompilat von 32- und 64bit Varianten der Objects, der statischen Archive und von executables.

  • Das Mischkompilat (Universal Binary für 32- und 64bit Varianten) ist notwendig um die zentrale Bibliothek libcups.2.dylib für beide Architekturen anzubieten. Ansonsten würde so ziemlich alle 32bit Applikationen beim Start crashen.

    Leider reicht das o.g. configure nicht aus um die dynamische Bibliothek auch auf 32bit zum Kompilieren (auf einem aktuellen 64bit Rechner). LDFLAGS greift hier nicht – deshalb muss manuell in der Datei Makedefs in der Zeile ARCHFLAGS ebenfalls -arch i386 -arch x86_64 eingetragen werden. Danach nur noch

  • make
  • make install

Jetzt noch ein bischen zittern beim Neustart und dann war’s das schon,
hier ein fertiges CUPS 1.4.8 Paket für Mac OS X Snow Leopard OHNE JEGLICHE GEWÄHR!

9 Gedanken zu „cups-polld im busy-loop“

  1. Danke für die ausführliche Beschreibung und gründliche Analyse – und den Fix!
    Wir sind hier in genau dasselbe Problem reingelaufen mit unseren Macs und dem zentralen, CUPS-basierten Drucken…

    Antworten

  2. Hallo,
    vielen Dank fuer diese Analyse und die Anleitung, habe ebenfalls das problem mit dem 100% load cups-polld beobachtet.
    Leider kommt es auf meinem system zu einem compiler/linker-fehler. Waere dankbar fuer jeden hinweis.
    MacOS 10.6.8 Darwin Seneca.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
    patch hab ich manuel eingefuegt, configure ging ohne probleme, danach Makedefs editiert.

    Hier die relevante fehlermeldung:

    Making all in notifier…
    Compiling dbus.c…
    dbus.c: In function ‘main’:
    dbus.c:362: warning: implicit declaration of function ‘dbus_message_append_iter_init’
    dbus.c:366: warning: implicit declaration of function ‘dbus_message_iter_append_string’
    dbus.c:403: warning: implicit declaration of function ‘dbus_message_iter_append_uint32’
    dbus.c:445: warning: implicit declaration of function ‘dbus_message_iter_append_boolean’
    dbus.c: In function ‘main’:
    dbus.c:362: warning: implicit declaration of function ‘dbus_message_append_iter_init’
    dbus.c:366: warning: implicit declaration of function ‘dbus_message_iter_append_string’
    dbus.c:403: warning: implicit declaration of function ‘dbus_message_iter_append_uint32’
    dbus.c:445: warning: implicit declaration of function ‘dbus_message_iter_append_boolean’
    Linking dbus…
    ld: warning: in /opt/local/lib/libdbus-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
    Undefined symbols for architecture i386:
    „_dbus_error_init“, referenced from:
    _main in dbus.o
    „_dbus_bus_get“, referenced from:
    _main in dbus.o
    „_dbus_message_iter_append_uint32“, referenced from:
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    „_dbus_message_iter_append_boolean“, referenced from:
    _main in dbus.o
    „_dbus_message_iter_append_string“, referenced from:
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    „_dbus_message_append_iter_init“, referenced from:
    _main in dbus.o
    „_dbus_error_free“, referenced from:
    _main in dbus.o
    „_dbus_connection_send“, referenced from:
    _main in dbus.o
    „_dbus_message_unref“, referenced from:
    _main in dbus.o
    „_dbus_message_new_signal“, referenced from:
    _main in dbus.o
    „_dbus_connection_get_is_connected“, referenced from:
    _main in dbus.o
    „_dbus_connection_flush“, referenced from:
    _main in dbus.o
    „_dbus_connection_unref“, referenced from:
    _main in dbus.o
    ld: symbol(s) not found for architecture i386
    collect2: ld returned 1 exit status
    Undefined symbols for architecture x86_64:
    „_dbus_message_iter_append_uint32“, referenced from:
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    „_dbus_message_iter_append_boolean“, referenced from:
    _main in dbus.o
    „_dbus_message_iter_append_string“, referenced from:
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    _main in dbus.o
    „_dbus_message_append_iter_init“, referenced from:
    _main in dbus.o
    ld: symbol(s) not found for architecture x86_64
    collect2: ld returned 1 exit status
    lipo: can’t open input file: /var/folders/io/ioEBb2-HHO4gGcNcdoQ2fU+++TI/-Tmp-//cctM7p26.out (No such file or directory)
    make[1]: *** [dbus] Error 1
    make: *** [all] Error 1

    Der selbe fehler tritt auch waehrend configure auf, steht aber nur im config.log:
    …
    configure:8680: checking for DBUS
    configure:8683: result: yes
    configure:8695: checking for dbus_message_iter_init_append
    configure:8751: gcc -o conftest -arch i386 -arch x86_64 -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include
    -DDBUS_API_SUBJECT_TO_CHANGE -arch i386 -arch x86_64 conftest.c -L/opt/local/lib -ldbus-1 -lpthread >&5
    ld: warning: in /opt/local/lib/libdbus-1.dylib, file was built for unsupported file format which is not the architecture
    being linked (i386)
    Undefined symbols for architecture i386:
    „_dbus_message_iter_init_append“, referenced from:
    _main in ccPFEJWs.o
    ld: symbol(s) not found for architecture i386collect2: ld returned 1 exit status
    lipo: can’t open input file: /var/folders/io/ioEBb2-HHO4gGcNcdoQ2fU+++TI/-Tmp-//cc6qdkGb.out (No such file or directory)

    Antworten

  3. Sorry, hab es selbst rausgefunden: ich benutze MacPorts und hatte dbus als abhaengikeit installiert, allerdings eine alte version. Einmal alles updaten mit
    > port selfupdate
    > port upgrade outdated
    hat geholfen.

    Antworten

  4. Hi,

    hier ein Warnhinweis für Benutzer von alter Software unter PPC-Emulation (Rosetta).

    Nach erfolgreicher installation wie im Artikel beschrieben funktionieren alte PowerPC anwendungen auf meinem 10.6.8 System nicht mehr. Die Anwendungen crashen unmittelbar nach dem Start. Ich gehe mal davon aus das das mit dem update zu tun hat, und ein Hinweis auf die ursache ist:

    „Das Mischkompilat (Universal Binary für 32- und 64bit Varianten) ist notwendig um die zentrale Bibliothek libcups.2.dylib für beide Architekturen anzubieten. Ansonsten würde so ziemlich alle 32bit Applikationen beim Start crashen.“

    Ich vermute, dass hier eine library für eine weitere Architektur (PPC) benötigt wird. Bin auf der suche nach einer Lösung. Weiss jemand wie sich eine PPC version für die PPC-Architektur übersetzen lässt?

    Antworten

    1. Und hier schon die Lösung, alles ohne Garantie usw. xD:
      – Der arch name der PowerPC Architektur ist, na? … ppc
      D.h.: man muss an zwei Stellen der obigen Anleitung „-arch ppc“ hinzufügen. Meine Kommandozeile:

      > make clean
      wichtig falls man im gleichen verzeichnis gebaut hat.
      > ./configure CFLAGS=“-arch ppc -arch i386 -arch x86_64″ LDFLAGS=“-arch ppc -arch i386 -arch x86_64″ –disable-dbus

      –disable-dbus deshalb, da, falls man dbus über das MacPorts system eingebunden hat, make fehlschlägt (werden keine PPC bindings gebaut?). Hat man kein dbus, kann man das wahrscheinlich weglassen. Es können natürlich noch weitere Pakete betroffen sein.

      > … – deshalb muss manuell in der Datei Makedefs in der Zeile ARCHFLAGS ebenfalls -arch ppc -arch i386 -arch x86_64 eingetragen werden

      > make
      > make install

      und neustart.

      Erfolg: Bei mir laufen jetzt auch die legacy PPC programme, Drucken funktioniert aus beiden alten und neuen Programmen.

      BTW.: So ein kritisches Update wäre doch eigentlich Apples job, oder??

      Antworten

  5. Hi,

    PPC hatte ich nicht mehr auf dem Radar, denn Mac OS X Snow Leopard hat ja keine PPC Unterstützung mehr.
    Aber ich vergaß Rosetta – ich hab selber noch eine Anwendung, die allerdings nicht gegen die libcups linkt.

    Danke für den Hinweis,
    Harald

    BTW: Natürlich wäre es Apple’s Aufgabe – aber die verweisen einen auf Mac OS X Lion, bei der DAS Problem nicht mehr existiert (dafür wahrscheinlich viele andere neue…)

    Antworten

  6. Seit einiger Zeit habe ich bemerkt, dass Paketmarken die von Snow Leopard aus gedruckt werden fehlerhaft sind. Der Barcode wird nicht richtig gedruckt – es erscheint nur ein leichtes Pixelmuster.
    Ich hatte das selber gebaute CUPS Paket im Verdacht – tatsächlich existiert das Problem auch mit einem nicht veränderten CUPS aus Snow Leopard.

    Antworten

  7. Hallo Harald!

    Ich habe mit Cups 1.5.3 versucht und alles kompiliert sich wie voraussichtlich und ich habe mich einer .PKG zu erstellen und alles sieht von PackageMaker gut aus – aber nichts wird Installiert…

    Haben Sie das selber erlebt? -Und wie haben Sie Ihrer .PKG selber hergestellt?

    Viele grüße,

    Søren, Dänemark

    Antworten

    1. Hi Søren,

      Sag übrigens ruhig „Du“ 🙂
      Leider bin ich auch kein Experte im .pkg erstellen. Bei mir gab es keine Probleme, ich bin mir nicht mal mehr sicher ob ich das Paket mit dem GUI oder auf der Kommandozeile erstellt habe…

      Ich kann mich aber noch an 2 Dinge erinnern, die ich für das Erstellen des .pkg machte:
      1. Die Ordnerstruktur nachbilden (z.B. /usr/lib) für die zu ersetzenden Dateien bspw. /usr/lib/libcups.2.dylib
      2. Die Rechte und die Eigentümerschaft (owner:group) der selbstkompilierten Dateien so zu ändern, dass sie den Originalen entsprechen.

      Vielleicht liegt es daran? Zudem bin ich bewusst bei Version 1.4.x geblieben um die Änderungen minimal zu halten. Bei Version 1.5 bestehen vielleicht Abhängigkeiten zu Systemkomponenten (pthreads,SSL…) die Snow Leopard nicht erfüllen kann. Allerdings müsste dieses Problem schon bei der Kompilierung oder beim Linken auftreteten und nicht erst im Bauen des Paketes.

      Viel Erfolg und viele Grüße ins schöne Dänemark
      Harald

      Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.