Immer aktuell - CW Cache Patch

[w33dburner]

@OnkelAtze Die Last ist ordentlich, was für eine cachesize ist da zu der Zeit denn am Start? Ist die Last auch ohne Debug-Log so hoch?

Hier eine kurze Anleitung, wie man einen Backtrace erstellt, mit dem man die Ursache ermitteln kann.

Wenn ihr diesen dann postet, kann jemand evtl. was damit anfangen und die Ursache ausmachen/beheben.

Installiert euch "gdb"
Debian/Ubuntu und Derivate:

sudo apt install gdb

Baut eure OSCam und nehmt die oscam*.debug als binary (die größere!) und verwendet diese.

Erstellt euch eine Datei namens "run", im Ordner wo die OSCam-Binary liegt, mit folgendem Inhalt:

handle SIGPIPE nostop noprint pass
handle SIG62 nostop noprint pass
run -d1 -r0 -c/path-to-your-oscam-config/

Ersetzt "/path-to-your-oscam-config/" mit dem entsprechenden Pfad zu eurem OSCam-Config-Ordner.
Weitere Startparameter können dahinter angehangen werden.

Startet nun OSCam:

gdb oscam -x run

Nun seht ihr die Ausgabe von startenen Threads usw.

Wenn OSCam nun mit einem segfault aussteigt erscheint etwas in der Art:

Program received signal SIGSEGV, Segmentation fault.
...
...

Und weitere Zeilen.

nun in der gdb-shell "bt" eingeben:

(gdb) bt
#0 0x.......
#1...
#n...
(gdb)

Die Zeilen in den letzten beiden Code-Blöcken sind die relevanten um sich der Sache annehmen zu können.

 

[OnkelAtze]

Die Last ist ordentlich, was für eine cachesize ist da zu der Zeit denn am Start?

Cache Size mom: 3940
meist ~ 3000 - 5000

Ist die Last auch ohne Debug-Log so hoch?

Die OSCam lief normal, ohne Debug mit den Angaben wie gestern geschrieben.
Sofern ich cacheex_cw_check_for_push = 1 setze und dann speichern klicke (im User / CacheEx2) steigt die Last exorbitant an.

vG OA

Ohne die Funktion, mit meinen Parametern (siehe Spoiler -> Immer aktuell - CW Cache Patch) läuft alles perfekt.

An dieser Stelle nochmals vielen Dank für Deine tolle Arbeit.

vG OA

 

[w33dburner]

Edit! :
Da habe ich das localgenerated-flag feature mit dem tryfix des cx3-crash's kaputt gemacht.... Fix folgt dann bei Zeiten

Kleines Update mit nem Feature zum Service-spezifischem setzen der no_wait_time-Funktion (bekannt aus den User-Settings).
Praktisch wenn sich lokale Karten langweilen, oder aber von einer CAID nicht alles lokal vorhanden ist, sehr oft via Cache kommt und die anderen Services gerne ohne wait_time lokal bedient werden sollen.

Anwendung wie auch schon bei der 48bit-Thematik:

Dem Service das Flag "no_wait_time=1" mitgeben und gut ist.

[service_foo]
no_wait_time  =1
caid          = ABCD
provid        = 123456
srvid         = CAFF,EBAB,E000

Zudem inkl. Tryfix für crashes bei CacheEx3 bzgl localgenerated-flag

@OnkelAtze bei dir würde ich auf ein Lastproblem tippen, da die cacheex_cw_check_for_push durchaus was zu tun hat, mach doch mal ein backtrace, vllt sieht man da was.

Edit! :
Da habe ich das localgenerated-flag feature mit dem tryfix des cx3-crash's kaputt gemacht.... Fix folgt dann bei Zeiten

 

[dsc]

Danke w33dburner diese Version rennt bei mir !!

 

[OnkelAtze]

@w33dburner

Danke für den neuen Patch! Wurde noch etwas geändert?

Ich habe eben mit dem Patch eine neue OSCam (extra auch mit debug) gebaut, wollte aber erst "normal" testen & was soll ich sagen, bisher läuft die oscam völlig normal mit cacheex_cw_check_for_push = 1 gesetzt.

OSCam	User: 4.71 %	System: 3.87 %	Summary: 8.57 %

Cachesize: 4039 - also auch nicht mehr oder weniger als sonst

Er macht auch was er soll: 2020/04/17 17:49:14 6D6DF6D3 p (cacheex) push denied - cacheex_check_cw.counter: 2 > er->cw_count: 1

Nachdem ich mir den 512er Log angesehen, hier rein kopiert und auf die Statusseite zurückgeschalten habe, stieg die Last enorm an:

OSCam	User: 51.31 %	System: 10.13 %	Summary: 61.44 %

Zurück ins Log, auf 0 gesetzt:

OSCam	User: 6.79 %	System: 3.81 %	Summary: 10.60 %

Ich hatte bei den Test's zuvor auch immer den 512er Log beobachtet, um zu sehen ob die Funktion greift & diesen nicht wieder auf 0 zurückgesetzt.
(hätte mir auch früher einfallen können - ich weiß)

Nachtrag:
Schalte ich die Funktion (cacheex_cw_check_for_push = 1 ) aus und schaue mir den 512 Log an, steigt die Last zwar, aber nicht so extrem:

OSCam	User: 23.78 %	System: 7.93 %	Summary: 31.70 %

vG OA

 

[dArk4psyco]

Kann es sein das mit der Verison 9.1.1 keine localgenerated flags mehr im log kommen?

 

[w33dburner]

Ups, hab ich es kaputt gemacht?
Gucke es mir später an.

 

[kesyhack]

Gracias amigo, lo probaremos

 

[OnkelAtze]

Lokal generierte CWs werden geflaggt und dieses Flag wird via CacheEx 2/3 (cs378x & cccam-Protokoll) weitergereicht.

@w33dburner

werden hierbei auch Readereinträge mit z.B. localcards = 1843:000000,003411,008011 (meine lokale HD+ am VPS) berücksichtigt?

vG OA

 

[BigDaddy2198]

Setz das Flag dann Zuhause beim local Reader, mit dem Eintrag werden keine Flags gesetzt und das ist auch gut so :smile: wenn beide oscam gepatched sind wird das Flag weitergereicht

 

[OnkelAtze]

Ok, ich habe daheim als "lokal Reader" HD+ in einer Vu+ Ultimo4K, diese hat keine CacheEx Verbindung zum Server, da ich mir "gedacht" habe, die meisten Zugriffe auf die Karte kommen eh vom VPS, somit reicht es wenn der dort generierte Cache weitergeleitet wird.

vG OA

 

[tem_invictus]

Du könntest im Reader auf deinem VPS "localcards =" setzen. Dann wird der Proxy als lokaler Reader gehandhabt und somit sollte es wieder mit Flag versehen werden.

 

[BigDaddy2198]

Ich glaube nicht das dann das Flag gesetzt wird, aber zu 100% weiß ich es auch nicht, soweit ich weiß setzt er das Flag nur wenn es kein Network Reader ist, und das bleibt es auch mit localcard = , somit sollte es nicht gesetzt werden, was auch so sein sollte, sonst kann jeder einen Network Reader Flaggen wo die Quelle verseucht ist mit schlechten Cache, damit wäre das ganze eher nutzlos

 

[tem_invictus]

@BigDaddy2198 , da hast du recht. Damit wäre das Flag nutzlos, wenn man es so einfach aushebeln kann

 

[w33dburner]

Fix broken localgenerated-flag
localgenerated-Log(512) modified:

cacheex: received ECM with localgenerated flag CAID@PROVID:SID reader/username