"Deadlocks" bei Privoxy in ds-mod.

[hummingbird_de]

Hi,

einer der Gründe für mich ds-mod auf meine Fritz!Box Fon zu installieren, war das Auslagern von Privoxy auf einer meiner Infrastrukturgeräte. Endziel soll sein, eine Zwangsumleitung der Ports 80 & 443 auf den Proxy zu realisieren.

Allerdings sind erste Tests mit Privoxy auf der FBF nicht sehr ermutigend. Die Performance ist eigentlich gut im Vergleich zum Privoxy auf dem Desktop, bis dann nach einer unspezifizierbaren Zeit nichts mehr geht. Und ich meine nichts mehr, das durch den Privoxy auf der FBF geht. Nur ein Umstellen auf Desktop-Privoxy oder gar keinen Proxy hilft. Den Privoxy auf der FBF kann ich erst nach einem Reboot der Box wieder nutzen.

Ich bin zur Zeit der einzige im Netzwerk der Privoxy auf der Box zum Test nutzt. Der Load der Box ist normal, der Prozess läuft scheinbar normal, aber Zugriffe gehen einfach irgendwann nicht mehr.

Version: ds-mod 0.2.9-04.06 (FW.: 06.04.15) mit und ohne Privoxy Patch vom 03.12.2006 und OpenVPN mit LZO.

Ich weiß, die "Maschine" FBF ist nicht die schnellste, aber so instabil?

Habt Ihr das Phänomen auch?

Vielen Dank schon mal für Eure Hilfe.

regards
hummingbird_de

 

[olistudent]

Den Privoxy auf der FBF kann ich erst nach einem Reboot der Box wieder nutzen.

Ein Restart des Privoxy über das dsmod-Webinterface hilft nicht weiter? Wenn es reproduzierbar alle paar Stunden auftritt, dann kannst du den syslogd remote auf deinen PC loggen lassen und den Log nach Auffälligkeiten durchsuchen (Kiwi).

MfG Oliver

 

[hummingbird_de]

Hi Oliver,

nun, von ein paar Stunden kann keine Rede sein, eher irgendetwas zwischen 1 und 60 Minuten. Es läßt sich sehr einfach reproduzieren mit MSIE und firefox.

Subjektiv hatte ich schon den Eindruck, einige Zeit geöffnete URLs verursachen das Problem sofort.

Nun, den Syslog werde ich mir mal anschauen.

Bis dann
Frank

 

[olistudent]

Ich weiß jetzt garnicht wo der Privoxy hinlogt. Eventuell musst du die Messages vom Privoxy noch umleiten...
Hab Privoxy nicht auf der Box, sonst würde ich das mal probieren.

MfG Oliver

 

[knox]

ich wollte das problem heute mal nachvollziehen und bin dabei auf ein anderes problem gestoßen: privoxy ist auf einmal sau lahm?!

selbst wenn ich die filter komplett abstelle (und keine weiterleitung an tor eingerichtet ist), dauert der aufruf einer einfachen html seite ohne bilder eine gefühlte ewigkeit.

ich weiss aber genau, dass früher nicht der fall war. auch ein blick auf die ausgabe von top zeigt weder massiven speicher- oder cpu-fraß - was macht das ding bitte schön?

(da ich in letzter zeit meine tor verbindungen alle mit hilfe des prima tor button plugin aufgebaut habe, hab ich den privoxy nicht mehr wirklich benutzt und das ganze ist erst heute aufgefallen.)

 

[danisahne]

Cached der Privoxy auch? Ich kenn das Teil nichts so und hab auch keine Erfahrung mit diesem Proxy.

Wenn ja, wie groß ist denn euer Cache? Proxies brauchen vor allem Hauptspeicher. Es müssen alle Verwaltungsstrukturen über den Cacheinhalt im Speicher gehalten werden können, sonst geht die Performanz eines Proxies in die Hose. Für Squid gibt es da so Faustegeln, die man sich ergoogeln kann.

Ob das natürlich das Problem ist?? Wie groß ist denn bei euch der Cache eingestellt?

Mfg
danisahne

 

[knox]

Cached der Privoxy auch?

nein, der privoxy ist ein webfilter, kein caching proxy.

es wird also in erster linie cpu performance benötigt, der speicherbedarf hingegen ist nicht so groß.

ich werde versuchen, die sache zu ergründen. jede weitere zuarbeit, z.b. in form von logs o.ä. wäre sehr hilfreich.

 

[hummingbird_de]

Hi,

das mit dem nicht benötigten Speicher ist nicht ganz richtig. Privoxy und auch alle anderen Webfilter-Proxy benötigen Arbeitsspeicher.

Bei Privoxy sind das in etwa 4096KB/4MB damit er gut funktioniert. Er benötigt den Speicher um den Inhalt der aufgerufenen Seite zu "analysieren". Das geht natürlich erst wenn er die URL (bzw. Teile davon z.B. animierte GIFs etc.) in den Hauptspeicher der Privoxy Rechners geladen hat. In meinem Fall ist das ein FBFon mit 16MB RAM, wovon ohne Privoxy schon 15MB belegt sind. Hinzu kommt das natürlich CPU benötigt wird und die ist natürlich nicht super schnell in der FBF.

Privoxy auf dem Destop steht natürlich hier im Vergleich unendlich viel mehr Speicher und CPU zur Verfügung. Fairerweise muß ich noch erwähnen, Privoxy auf meinem WRT54G (OpenWRT, 16MB, 200MHz) hat ähnliche Probleme, wobei hier die CPU schneller ist. Allerdings habe ich dort keine "Deadlocks", sondern es ist einfach nur langsam und es fehlen Teile der URL wenn der Hauptspeicher voll läuft. Das ist aber auch so in der Doku beschrieben.

Also erstens kann ich mir nicht vorstellen, das das jemals schneller lief und zweitens ist m.E. weder die FBF noch ein WRT54G der richtige Rechner für Privoxy. Ich beschränke mich nun auf die Desktop-Version. Mal sehen wie FBF und WRT54G mit OpenVPN funktionieren.

Bis dann
Frank

[EDIT]Siehe dazu Anhang, Privoxy Desktop Version 3.0.3.[/EDIT]

 

[knox]

Also erstens kann ich mir nicht vorstellen, das das jemals schneller lief

das hat nichts mit vorstellung zu tun, sondern ist ein erfahrungsbericht. möglicher weise liegt der gefühlte performanceverlust aber auch an der erst kürzlich durchgeführten versionsumstellung.

Bei Privoxy sind das in etwa 4096KB/4MB damit er gut funktioniert.

wo hast du diese zahl her?

hier die ausgabe von top auf meiner 7170:

3090 root     S        716     1  0.0  2.3 privoxy

(2.3% des speichers werden belegt)

Hinzu kommt das natürlich CPU benötigt wird und die ist natürlich nicht super schnell in der FBF.

mit gut sortierten filtern hält sich der cpu bedarf in grenzen.

In meinem Fall ist das ein FBFon mit 16MB RAM,

das ist sicherlich ein problem.

 

[hummingbird_de]

@knox

Aus der dokumentierten Privoxy conf-Datei:

#  
#  4.6. buffer-limit
#  =================
#  
#  Specifies:
#  
#      Maximum size of the buffer for content filtering.
#  
#  Type of value:
#  
#      Size in Kbytes
#  
#  Default value:
#  
#      4096
#  
#  Effect if unset:
#  
#      Use a 4MB (4096 KB) limit.
#  
#  Notes:
#  
#      For content filtering, i.e. the +filter and +deanimate-gif
#      actions, it is necessary that Privoxy buffers the entire document
#      body. This can be potentially dangerous, since a server could
#      just keep sending data indefinitely and wait for your RAM to
#      exhaust -- with nasty consequences.  Hence this option.
#  
#      When a document buffer size reaches the buffer-limit, it is
#      flushed to the client unfiltered and no further attempt to filter
#      the rest of the document is made. Remember that there may be
#      multiple threads running, which might require up to buffer-limit
#      Kbytes each, unless you have enabled "single-threaded" above.
#  
buffer-limit 4096

Beachte den Hinweis "Effect if unset". Habe ich mit Destop Versionen für Debian und WinXP und unter OpenWRT auf meine WRT54G überprüft. Es stimmt. Auf meiner FBF mit ds-mod & privoxy ist hier nichts gesetzt, d.h. ich tippe auf "unset" .....

mit gut sortierten filtern hält sich der cpu bedarf in grenzen.

Nun, sortiert sind die Filter nur im Bezug auf Strings in den URLs. Andere Filter arbeiten zwangsläufig unsortiert (z.B. animated GIFs etc.) und diese benötigen etwas vom wenigen Speicher und etwas von der wenigen Rechenpower. Meine Destops haben 512MB+ Hauptspeicher und 1500Mhz+ Taktfrequenz. Die würden mehrere Privoxys im Hintergrund auf der linken A.... absitzen. Siehe Screenshot im letzten Post.

Da Du nach Zuarbeitung gefragt hast, würde ich nochmal Tests mit Privoxy auf der FBF machen und den syslog für Dich mitschreiben lassen, ok?

Evtl. hast Du ja recht und das könnte auf der Box einigermaßen funktionieren.

Cherio
Frank

 

[knox]

#  
#  4.6. buffer-limit

vielen dank für den hinweis! so genau hab ich mir privoxy doku bisher nicht angeschaut. (ich habe privoxy in erster linie wegen der verwendung mit tor auf die box portiert, ohne mich weiter damit zu befassen)

mit sicherheit macht es sinn, diese option entweder mit ins webinterface aufzunehmen oder zumindest in der von privoxy_conf erstellten config einen realistischen wert einzutragen.

Da Du nach Zuarbeitung gefragt hast, würde ich nochmal Tests mit Privoxy auf der FBF machen und den syslog für Dich mitschreiben lassen, ok?

ja, das ist ne idee. aber zum glück ist das package open-source und jeder kann sich auch direkt an der weiterentwicklung beteiligen...

Evtl. hast Du ja recht und das könnte auf der Box einigermaßen funktionieren.

als ich die ersten versionen des package erstellt hatte, hab ich es auch selbst getestet und es war einigermaßen benutzbar. wie schon erwähnt benutze ich privoxy aber zur zeit nicht mehr (siehe an anderer stelle).

und noch etwas off-topic:
das tinyproxy package hat eigentlich bei mir immer gut funktioniert, aber ich habe meine eigenen änderungen bisher nie in ein "fertiges" package umgesetzt - nicht zuletzt, weil die verbindung mit tor auf den ersten blick nicht möglich schien. vielleicht macht es auch mehr sinn, die kräfte lieber wieder in diese richtung zu lenken?
+ tinyproxy ist schnell und funktioniert gut auf der fbox
+ tinyproxy beherrscht angeblich den upstream an einen socks proxy (für tor)
- dazu muss aber libsocks auf die box portiert werden
- der ursprüngliche author des ds-mod package gibt keine lebenszeichen mehr von sich

nachtrag: alles wissenswerte zu tinyproxy im wiki

 

[Dacoco]

Ich habe ähnliche Probleme. Privoxy hängt sich sehr häufig - manchmal schon nach wenigen Sekunden/Minuten auf und ich kann dann nur noch den Prozess per kill-9 stoppen und im Freetz Interface neu starten.

Hat jemand ne Lösung dafür?

 

[olistudent]

Leg dir bitte mal eine Signatur zu. Und poste dein .config.

MfG Oliver

 

[Dacoco]

/mod/etc/privoxy/config ?

confdir /mod/etc/privoxy
actionsfile standard.action
actionsfile default.action
filterfile default.filter
enable-edit-actions 0
logdir /var/log
logfile privoxy.log
# debug 4096
debug 8192
actionsfile /tmp/flash/user.action
filterfile /tmp/flash/user.filter
toggle 1
enable-remote-toggle 0
enforce-blocks 1
listen-address 192.168.178.1:8118

Ausserdem habe ich bisher nur per Remote (VPN) getestet.
Ich habe jetzt testweise mal die Proxydaten zu Hause am Rechner eingestellt. Mal sehen ob der sich auch dauernd aufhängt.

EDIT: Zu Hause (also direkt ohne VPN) scheint es besser zu laufen. Bisher keine Probleme.
Wie kann ich den Proxy so optimieren, dass er im VPN-Modus besser läuft?


btw - Die Filter und Blockingoptionen von privoxy brauche ich eigentlich nicht. Ich will nur über den VPN Tunnel mit meiner IP von "zu Hause" surfen.
Wenn das auch einfacher geht, immer her damit (Habe von dropbear gelesen, weiss aber nicht wie ich das einrichten muss?)

 

[olistudent]

Das Problem hängt mit einem alten pthread Bug in der uClibc zusammen. Im trunk ist das bereits behoben. In der stable ist das leider nicht so einfach. Die SSH Tunnel Lösung sollte über google zu finden sein.

MfG Oliver

 

[Dacoco]

Gegoogelt habe ich schon aber nichts finden können.

Aber wenn das Problem im Trunk nicht mehr auftritt? Sehe ich das gemäß Anleitung richtig, dass ich einfach den trunk auschecke und dann mein Image genauso zusammenkompiliere wie bei der stable version?
Und wenn ja - Kann ich das dann komilierte Trunk-Image einfach per AVM Firmwareupdate einspielen oder muss ich die Box erst komplett mit Recovery Image platt machen?

 

[olistudent]

Ja, genau so aufspielen wie stable.

MfG Oliver

 

[Dacoco]

Okay das Trunk-Compile und das Update hat schonmal geklappt.
Mal sehen ob privoxy über VPN nun besser läuft.

Eine andere Sache an alle Profis hier. Wenn ich vom Fritzload FTP Sachen runterziehe bricht er bei ziemlich genau 7MB ab und sagt die Datei sei fertig geladen. Sie ist aber viel größer. Hat das auch mit dem oben angesprochenen Bug zu tun? Das ist leider auch nach dem Update auf die Trunk Version der Fall?
Es wäre echt super wenn jemand dafür ne Idee hätte. Und wenns nur ist wo sich die Logs befinden o.ä.. Ein einfacher Verweis auf die Suche wäre jetzt nicht so der Hit

 

[Silent-Tears]

Fritzload hat nichts mit Freetz zu tun. Frag doch die Entwickler davon mal....

 

[Dacoco]

Sehe ich prinzipiell ähnlich, allerdings weiss ich ja nicht was netzwerk bzw. ftp mäßig an der Box durch Freetz verändert wird. fritzload lief ja vorher einwandfrei. Bftp ist übrigens nicht eingeschaltet.

Er bricht im übrigen immer nach etwa 60 Sekunden ab. Zu Hause schaffe ich damit etwa 70 MB der Datei und per https bzw. aus der Ferne etwa 7 MB.

EDIT: Das eigentlich Deadlock Problem hat sich mit dem "Update" auf trunk nun erledigt. Danke dafür.
Da bzgl. FritzLoad keiner ne Idee hat habe ich dafür n Ticket aufgemacht.