cccam bleibt teilweise stehen- keine Infos + kein WebIF mehr

[randy]

Hi


so, ich habe eigentlich wegen dem Problem meinen IPC neu installiert - und jetzt habe ich es wieder genau so wie auf der alten Hardware...

Folgendes Tritt auf:
CCcam schmiert irgendwie so "halb ab" das bedeutet, dass noch 2-3 Geräte funktionieren - 2-3 eben nicht.
Zu diesem Zeitpunkt wenn ich über cccaminfo drauf schaue - kann ich nicht mehr aktualisieren. Es dauert ewig und funktioniert auch nicht.

Ich hätte es dann über Putty probiert über c -iac z.b.
Aber auch da passiert nix mehr.

Starte ich CCcam per Putty neu - funktioniert sofort wieder alles wie es soll.
Leider aber nur sehr begrenzt (schwer abzuschätzen)
Ich habe jetzt auch schon verschiedene cccam Versionen getestet!

Wenn ich das Crashlog ansehen will, werde ich auch nur beglückwünscht, dass alles i.o ist

Die Auslastung ist wirklich sehr niedrig.
Kernel Version 2.6.32-5-486
Distro Name Debian 6.0.6
Auslastung 1.00 1.01 1.00


Hat jemand evtl. einen guten Ansatzpunkt, wie ich suchen könnte?! Ich habe wirklich keine Ahnung mehr.


tausend Dank für jede Antwort!

viele Grüße

[jensebub]

...Die Auslastung ist wirklich sehr niedrig.
...Auslastung 1.00 1.01 1.00

Ich denke, da wird schon dein Fehler sein,...:

Auslastung.JPG (8.96 KiB) 2502 mal betrachtet

Gruß
jensebub

[TommyH99]

und lass uns teilhaben an deinem Log ... syslog und cccam ... paar minuten vor und nachdem "Problem"

2-3 Geräte? heißt Receiver?

installiere dir mal "htop" und guck dir mal die Auslastung an. Ich glaub halt das es an einem Client von dir liegt

Und natürlich die Config von cccam würde mich interessieren.

[randy]

Ach so - ich dachte eher, das die Auslastung mit 1.xxx eher minimal ist

Genau. Es sind jeweils nur Dreamboxen mit CCCam > 2.1.3

CCcam.cfg

Spoiler

Show

C: Line { 0:0:1 }
C: Line


F: intern1 pass1 2 1 0 { 0:0:2, 1834:0, 09C4:0 }
F: intern2 pass2 2 1 0 { 0:0:2, 1834:0, 09C4:0 }
F: intern3 pass3 1 1 1 { 0:0:2, 1834:0, 09C4:0 }
F: extern1 pass1 2 1 0 { 0:0:2, 1834:0, 09C4:0 }
F: extern2 pass2 1 1 0 { 0:0:2, 1834:0, 09C4:0 }
F: extern3 pass3 1 0 0 { 0:0:2, 1838:0, 09c7:0 }


SERVER LISTEN PORT : 12000

WEBINFO LISTEN PORT : 16001
WEBINFO USERNAME : cccam
WEBINFO PASSWORD : cccam

#Lokale Karten - (Smargo Reader)

SERIAL READER : /dev/ttyUSB0 smartreader+
SERIAL READER : /dev/ttyUSB1 smartreader+
SERIAL READER : /dev/ttyUSB2 smartreader+
SERIAL READER : /dev/ttyUSB3 smartreader+
SERIAL READER : /dev/ttyUSB4 smartreader+
SERIAL READER : /dev/ttyUSB5 smartreader+

CAID PRIO FILE : /var/keys/CCcam.prio
PROVIDERINFO FILE : /var/keys/CCcam.providers
CHANNELINFO FILE : /var/keys/CCcam.channelinfo
#SOFTKEY FILE : /var/keys/SoftCam.Key
#AUTOROLL FILE : /var/keys/AutoRoll.Key

#Allgemeine Einstellungen
ALLOW TELNETINFO: no # Ansonsten ist PORT 16000 offen
MINIMUM DOWNHOPS: 1 # Nur Karten annehmen die weitergegeben werden koennen
DISABLE EMM : no # Ansonsten kommen keine Updates auf die Karten
EXTRA EMM LEVEL : no # Ansonsten werden EMM-Updates von HOP2 Clients angenommen
SHOW TIMING : yes # Antwortzeiten der Karten anzeigen
MINIMUM CLIENT VERSION : 2.1.0

Den Zeitpunkt wann es soweit ist, kann ich nur schwierig finden - das kann von 5 min bis zu ein paar Stunden dauern.
Aber kann mir wirklich ein einziger Client das ganze killen?!

im cccam log sehe ich nur die ecms hin und her flitzen, und die jeweiligen Zeiten.

im Syslog sehe ich eigentlich auch nur über den ganzen Zeitruam die ecms und jede Minute den Watchdog.
Was ich noch gesehen habe:
c bc liefert:

Spoiler

Show

Feb 26 20:18:20 debian66 CCcam: kick 187.147.99.***(), bad command
Feb 26 20:18:20 debian66 CCcam: kick 187.147.99.***(user1), bad command
Feb 26 20:18:51 debian66 CCcam: kick 187.147.99.***(user1), bad command
Feb 26 20:18:59 debian66 CCcam: kick 187.147.99.***(user1), bad command
Feb 26 20:20:34 debian66 CCcam: kick 192.168.0.x(lokal1), bad command
Feb 26 20:20:44 debian66 CCcam: kick 192.168.0.x(lokal1), bad command

Boa die CPU Auslastung ist krass:

Spoiler

Show

top - 21:16:45 up 5:25, 1 user, load average: 1.02, 1.02, 1.00
Tasks: 90 total, 1 running, 89 sleeping, 0 stopped, 0 zombie
Cpu(s): 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3375544k total, 153688k used, 3221856k free, 7664k buffers
Swap: 6302712k total, 0k used, 6302712k free, 72996k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1135 root 20 0 80948 3848 1744 S 99.4 0.1 311:20.01 CCcam.x86
1076 root 20 0 59352 5584 2032 S 0.3 0.2 0:30.37 fail2ban-server
16299 root 20 0 2440 1144 900 R 0.3 0.0 0:00.12 top
1 root 20 0 2036 712 620 S 0.0 0.0 0:01.03 init

Aber kann es wirklich sein, dass auf einmal ein kleiner Atom dafür nicht reicht und auf Last rennt?!

und noch htop

Spoiler

Show

CPU[||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%] Tasks: 67 total, 2 running
Mem[||||| 71/3296MB] Load average: 1.09 1.04 1.01
Swp[ 0/6154MB] Uptime: 05:28:16

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1192 root 20 0 80948 3848 1744 R 98.0 0.1 5h13:20 /var/emu/cccam/CCcam.x86 -v -t
16446 root 20 0 2504 1276 988 R 1.0 0.0 0:00.32 htop
15924 www-data 20 0 26168 8840 3524 S 0.0 0.3 0:13.71 /usr/sbin/apache2 -k start
1 root 20 0 2036 712 620 S 0.0 0.0 0:01.02 init [2]
308 root 16 -4 2368 852 404 S 0.0 0.0 0:00.08 udevd --daemon
445 root 18 -2 2388 744 320 S 0.0 0.0 0:00.00 udevd --daemon
787 daemon 20 0 1812 500 408 S 0.0 0.0 0:00.00 /sbin/portmap
799 statd 20 0 1940 812 680 S 0.0 0.0 0:00.00 /sbin/rpc.statd
965 root 20 0 28356 1640 1008 S 0.0 0.0 0:00.00 /usr/sbin/rsyslogd -c4
969 root 20 0 28356 1640 1008 S 0.0 0.0 0:04.38 /usr/sbin/rsyslogd -c4
971 root 20 0 28356 1640 1008 S 0.0 0.0 0:02.21 /usr/sbin/rsyslogd -c4
972 root 20 0 28356 1640 1008 S 0.0 0.0 0:00.01 /usr/sbin/rsyslogd -c4
986 root 20 0 1708 596 492 S 0.0 0.0 0:00.00 /usr/sbin/acpid
1002 root 20 0 24380 7116 3924 S 0.0 0.2 0:00.48 /usr/sbin/apache2 -k start
1029 root 20 0 3816 956 764 S 0.0 0.0 0:00.12 /usr/sbin/cron
1046 www-data 20 0 25652 8656 4104 S 0.0 0.3 0:10.79 /usr/sbin/apache2 -k start
1047 www-data 20 0 25284 7608 3432 S 0.0 0.2 0:00.79 /usr/sbin/apache2 -k start
1048 www-data 20 0 26592 9080 3708 S 0.0 0.3 0:08.31 /usr/sbin/apache2 -k start
1049 www-data 20 0 26484 9436 4116 S 0.0 0.3 0:14.09 /usr/sbin/apache2 -k start
1050 www-data 20 0 26100 9332 4076 S 0.0 0.3 0:09.56 /usr/sbin/apache2 -k start
1076 root 20 0 59352 5584 2032 S 0.0 0.2 0:00.22 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.
1077 root 20 0 59352 5584 2032 S 0.0 0.2 0:11.52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.
1078 root 20 0 59352 5584 2032 S 0.0 0.2 0:01.89 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.
1079 root 20 0 59352 5584 2032 S 0.0 0.2 0:02.02 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.
1081 root 20 0 59352 5584 2032 S 0.0 0.2 0:01.61 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.
1083 root 20 0 59352 5584 2032 S 0.0 0.2 0:11.55 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.
F1Help F2Setup F3SearchF4InvertF5Tree F6SortByF7Nice -F8Nice +F9Kill F10Quit

[jensebub]

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1135 root 20 0 80948 3848 1744 S 99.4 0.1 311:20.01 CCcam.x86

Da sieht man ganz deutlich, das CCcam Schuld an der Prozessorauslastung ist
Dies könnte sehr wohl aus der Vielzahl an BadCommand's kommen.
Die User kannst du auch mit einer fail2ban-jail bannen

Gruß
jensebub

[randy]

Aber die Frage die sich mir stellt - wie finde ich den Übeltäter denn raus?

Was genau sagt denn ein BadCommand in dem fall eigentlich aus? Dass der Client einen Fehler beim Zugriff verursacht hat?

/EDIT:
So nach einem cccam restart dümpelt die cpu Last bei 0,5-2% dahin...

[TommyH99]

und wahrscheinlich ist in dem Moment der User mit "bad commands" nicht Online?

1.) Client sollte nicht CCcam 2.2.x oder 2.3.0 verwenden
2.) Clients sollen die Finger von billig/clone Receiver lassen.
3) Wenn 1. und 2. nicht in Frage kommt - auf OScam Server wechseln.


Zum Testen ob es wirklich daran liegt, einfach mal für paar Stunden die Line von dem Typen deaktivieren und gucken ob was passiert

greez!

[randy]

genau die User kommen nicht mehr rein.
Das ist echt komisch

Hat jetzt die hohe cpu last was damit zu tun?

Es werden nur DM Geräte verwendet mit cccam ab 2.1.3. Also kein Schrott.

[Pavlodar]

Schalte mal client´s mit Cccam 2.3.0 aus und gucke ob es was ändert .

[TommyH99]

bzw änder einfach die verfixxte cccam version beim client wie beschrieben ... DM ist kein Schrott aber teuer hoch³