{"id":215,"date":"2011-09-26T02:43:10","date_gmt":"2011-09-26T00:43:10","guid":{"rendered":"http:\/\/www.instruyete.org\/?p=215"},"modified":"2011-09-26T02:43:10","modified_gmt":"2011-09-26T00:43:10","slug":"cups-polld-im-busy-loop","status":"publish","type":"post","link":"https:\/\/www.instruyete.org\/?p=215","title":{"rendered":"cups-polld im busy-loop"},"content":{"rendered":"

Falls man in seiner CUPS<\/strong> Konfiguration einen Host permanent abfr\u00e4gt (BrowsePoll<\/em>), und CUPS der Version 1.4.x einsetzt, kann es passieren, dass bei l\u00e4nger aussetzender Netzwerkverbindung zum BrowsePoll<\/em> Zielrechner der cups-polld<\/strong> Prozess in einen busy-loop ger\u00e4t aus dem der Prozess nicht mehr herauskommt.<\/p>\n

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\u00e4ngerem auf Mac OS X Clients erleben.
\nMac OS X 10.6.8<\/strong> beinhaltet derzeit CUPS 1.4.7<\/strong>, w\u00e4hrend Mac OS X Lion CUPS 1.5.x einsetzt, welches ein Bugfix f\u00fcr dieses Problem beinhaltet.<\/p>\n

Eine genaue Fehlerbeschreibgung und einen source patch gibt es auf den Bugs Seiten des Debian Projektes<\/a>
\nDie Seite wiederum widmet sich aber dem Problem unter Linux – um das Problem auf Mac OS X <\/p>\n

    \n
  1. reproduzierbar zu machen (und damit testbar)<\/li>\n
  2. zu l\u00f6sen<\/li>\n<\/ol>\n

    stellte ich folgende Vorgehensweise auf:<\/p>\n

      \n
    1. Auf dem Mac OS X Client wird der cups-polld<\/strong> Prozess mangels strace<\/em> mit der Aktivit\u00e4tsanzeige<\/em> beobachtet<\/li>\n
    2. Im Normallzustand war der letzte Call von cups-polld:
      \n_semwait_signal(..)
      \n<\/code><\/li>\n
    3. Auf Linux Seite wird nun die erste Firewallregel geschaltet
      \niptables -I OUTPUT 1 -p tcp -d --sport ipp -j REJECT --reject-with tcp-reset<\/code><\/li>\n
    4. Danach wartet man bis der cups-polld Prozess in die Phase
      \nrecvfrom(...)
      \n<\/code>kommt, danach wird auf Linux noch die 2 FW Regel gestartet.<\/li>\n
    5. iptables -I INPUT 1 -p tcp -s --dport ipp -j REJECT --reject-with tcp-reset<\/code><\/li>\n
    6. Danach wird nach ca. 7 Minuten der cups-polld Prozess in den busy-loop \u00fcbergehen.<\/li>\n<\/ol>\n

      Jetzt muss CUPS mit dem auf den Debian Seiten verf\u00fcgbaren Patch versehen werden. Dazu l\u00e4dt man derzeit auf den CUPS Seiten<\/a> die letze 1.4 Version herunter (1.4.8) und patcht diesen. Der Patch beschr\u00e4nkt sich auf die Datei cups\/request.c<\/em> und lautet folgendermassen
      \n
      \n+ {
      \n+ status = httpUpdate(http);
      \n+ }
      \n+- while (http->state == HTTP_POST_RECV);
      \n++ while (status != HTTP_ERROR && http->state == HTTP_POST_RECV);
      \n+
      \n+ DEBUG_printf((\"2cupsGetResponse: status=%d\", status));
      \n+ <\/code><\/p>\n

      Beim anschliessenden kompilieren unter Mac OS X ist nat\u00fcrlich die Entwicklungsumgebung notwendig, zumindest die gcc toolchain auf der Kommandozeile. Folgende Schritte sind notwendig:<\/p>\n