Script ausführen bei eingehenden Anrufen?

Status
Für weitere Antworten geschlossen.
Hi,
hab mit dem busybox mit "nc -w" drin (und der Änderung cut/awk) keine Probleme mehr (jeden Aufruf durch "nc -w 1" ersetzt). Da ich selber keine Images bauen kann (nix Linux) muß ich mir allerdings momentan mit einem separaten busybox in /var/tmp helfen (danke Oli), außerdem müsste ich noch das install Skript so ändern daß die alte Version aus der debug.cfg raus gelöscht wird... Dieses Wochenende komm ich wieder nicht dazu ;-(
Max
 
Na gut. Also hier erstmal der Testbericht mit der aktuellen Busybox:

Testablauf:
(Hab hier zunächst mal nur das callmonitor.sh-script getestet, nicht die debug.cfg-Änderungen in Max's image-file. Die hier beschriebene Methode hält dementsprechend nur bis zum nächsten reboot.)
- Mit mod-Baukasten von haveaniceday ein image mit verbesserter busybox gebaut (kann man auch fertige images *-mod-0.52 nehmen, da sind dann halt zusätzliche Sachen drin, die man hier nicht braucht).
- neues image geflasht.
- callmonitor.listener und callmonitor.sh(mit Änderung cut|awk) aus Max's tar-file auf /var/tmp kopiert (über tftp)
- yak auf Windows-PC installiert
- in callmonitor.listener ip-Adresse des PC's, auf dem yac läuft, eingetragen (über vi)
- killall telefon; telefon | var/tmp/callmonitor.sh

Ergebnis:
1. Super
2. Einzelheiten:
- Anruf über Festnetz: Popup auf Windows-PC mit Rufnummer
- Anruf über VoIP: Popup auf Windows-PC mit Rufnummer
- Anruf von Nummer, die in debug.cfg eingetragen ist(als #MSISDN=4711:eek:dekolonnje): Popup auf Windows-PC mit Rufnummer und Name
- Anruf von Nummer, die nicht in debug.cfg eingetragen ist: Popup auf Windows-PC mit Rufnummer und Anfang des Telefonbucheintrags, kompletter Telefonbucheintrag in debug.cfg
- in callmonitor.listener IP durch Hostname ersetzt (wie in multid.leases eingetragen): geht genauso wie vorher
3. Bugs
- s. Hinweis von Max: nc bricht nicht ab bei nicht erreichbarer IP
4. Schönheitsfehler
- yak zeigt ein unschönes 'Kästchen' am Ende der Rufnummer
Abhilfe: in yak-Aufruf echo durch echo -n ersetzen
- Rufnummern, die nicht in debug.cfg eingetragen sind und auch nicht in der Invers-Suche gefunden werden, werden mit leerem Namensfeld in debug.cfg eingetragen, und zwar bei jedem Anruf erneut.
Vorschlag: Nicht gefundene Rufnummern mit Caller=" Unknown" eintragen.

Fazit (6 Monate vor Jörg Schieb):
Dieses Script braucht jeder, der wissen will, wer anruft: Rufnummer und Name auf dem PC angezeigt, egal, ob in Anrufliste oder nicht. Sobald die Sache mit dem 'nc' gelöst ist, sollte das ins mod-Script rein. :nemma:

@Max-1896
Absolut stark!
Danke & Grütze
crusader
 
"nc" bricht dummerweise nicht ab wenn es keine Verbindung zum client herstellen kann,
Hmmm....
Also bei mir bricht "nc" in der Kommnadozeile nach ca. 2 sec ab mit der Meldung: "No route to host" (siehe Beispiel)
Code:
# echo "wobistdu" | nc 192.168.178.35 80
nc: connect: No route to host
#
Wenn ich den callmonitor bei ausgeschaltetem Computer laufen lasse und mehrmals angerufen werde, sehe ich auch keine zusätzlichen Prozesse auf der Fritz!Box (gecheckt mit ps). Neu gebootet hat die Fritz!Box auch noch nicht.
@Max:
Kannst Du tatsächlich aufgehängte Prozesse sehen oder ist das nur eine Vermutung ?

Gruß
crusader
 
Hallo Max. Erst mal ein Lob. Genau das suche ich. Fragen: Hast du eine Bugfreie Version oben und eine leichte Anleitung für Neulinge, was die Installation angebt. Frage 2: Wie sieht es mit einer Deinstallation aus. Soviel ich erfahren konnte ist das mit einem Firmwareupdate verbunden. Wie könnte man das wieder killen? Frage 3: Was ist wenn weitere FW von AMD draufgespielt wird. Ist deine Sache dann weg?
 
@crusader: Das könnte zB davon abhängen ob der Client feste IPs hat oder DHCP nutzt. Bei meiner fritz ist es zumindest reproduzierbar zu "Prozessleichen" gekommen wenn Clients nicht erreichbar waren, und wenn die Tabelle zu voll war hat die fritz gebootet. Mit dem neuen "nc -w 1" tritt beides nicht mehr auf. Hast Du den Test oben auf der Fritz oder auf nem anderen System gemacht, ich hatte mit cygwin auch ein völlig anderes Verhalten als auf der fritz, kann mich aber nicht mehr an die Details erinnern ?

@autodidakt: noch keine bugfreie Version zum runter laden verfügbar. Generell ist dieses Skript keine neue firmware, sondern nur ein skript was in einer Datei (/var/flash/debug.cfg) auf der Fritz gespeichert wird welche auch nach einem Reboot bestehen bleibt. Das Skript an sich bekommt man also ganz einfach wieder weg indem man die Datei wieder editiert (dort stehen meist auch andere Dinge drin), alternativ könnte jemand auch mal ein "uninstall" schreiben... Neue Firmwäre ändert nichts am Skript. Allerdings benötigt mein Skript eine modifizierte Firmware, mit einem geänderten "busybox". Vielleicht findet sich ja auch jemand der ein komplettes Image mit meinem Skript zusammenbaut...
 
@Max:
Den Test habe ich auf der Fritz!Box gemacht (Konstellation s. Signatur), indem ich in callmonitor.listener eine nicht-existente IP für yac eingetragen habe.
Hab's gerade nochmal mit 'ner nicht-existenten dbox wiederholt: keine Leichen, kein Absturz.
Wie meinst Du das mit DHCP ? Ob auf dem nicht-erreichbaren Client DHCP eingestellt ist, kann die Box doch nicht wissen ;-).

crusader
 
ich meinte damit wenn die IP in der multid.leases steht, aber nicht erreichbar ist... ich probier das daheim nochmal. Ich hab die letzten Tests allerdings mit der 08.03.29-mod052 gemacht. glaub ich.
 
hast Recht, Problem tritt mit dem originalen "nc" aus 08.03.29-mod052 auf die Schnelle getestet nicht auf:

192.168.178.35 gabs bei mir noch nie
192.168.178.23 gibt es, ist aber ausgeschaltet
192.168.178.10 gibt es, ist eingeschaltet, aber keiner lauscht

# echo "hierbinich" | nc 192.168.178.35 80
nc: connect: No route to host
# echo "hierbinich" | nc 192.168.178.23 80
nc: connect: No route to host
# echo "hierbinich" | nc 192.168.178.10 80
nc: connect: Connection timed out

bin jetzt ziemlich verwundert, als ich das oben geschrieben hatte hatte meine box gerade unmotiviert gebootet, und am nächsten Tag standen ein Haufen "nc" in der Prozesstabelle und verschwanden nicht. Entweder hatte Enrik doch Recht (er meinte es fehlt ein \n), ich habe zu dem Zeitpunkt ein anderes busybox benutzt (entweder das offizielle oder das das damals bei Enrik lag), oder ich spinne.

Werd das skript nochmal ein paar Tage mit Original mod052 und ohne "nc -w", aber ansonsten unverändert laufen lassen.

Max
 
@crusader:
ich versteh das zwar nicht wirklich, aber momentan gibt meine box bei "ps" ua aus:
388 root 376 S /bin/sh /var/tmp/callmonitor.sh
397 root 620 S telefon
484 root Z [sh]
487 root Z [sh]
493 root Z [sh]
494 root Z [sh]
502 root Z [sh]
515 root Z [sh]
518 root Z [sh]
524 root Z [sh]
525 root Z [sh]
533 root Z [sh]
560 root Z [sh]
561 root Z [sh]
569 root Z [sh]
570 root Z [sh]
578 root Z [sh]
581 root 416 S -sh
648 root 316 R ps -edaf
#

Hab also wieder ein paar sinnlos in der Gegend herum hängende Prozesse, und das nach einem Tag. Mit dem "nc -w 1" ist das nicht passiert, und da lief die fritz auch einwandfrei weiter. Ich vermute wenn ich morgen abend drauf gucke sagt uptime wieder weniger als 1 Tag.... Ich werde also den Parameter im Skript am Wochenende wieder hinzu packen, auch wenn ich das nicht verstehe.

Schade eigentlich, ich hätte das wirklich gerne auch unmodifiziert am laufen.
Max
 
@Max
Teufel auch. Bei mir sieht's genauso aus:
335 root 356 S /bin/sh /var/tmp/callmonitor.sh
345 root 612 S telefon
426 root Z [sh]
432 root Z [sh]
560 root Z [sh]
566 root Z [sh]
582 root Z [sh]
588 root Z [sh]
618 root Z [sh]
624 root Z [sh]
848 root 416 S -sh
983 root 316 R ps -edaf

aber erst seit dem letzten reboot. Davor hat ich absolut keine Zombies, ich schwöre.
Muß an irgendwas anderem hängen, denn meine ganze FBF hängt voller Zombies:
Code:
  PID  Uid     VmSize Stat Command
    1 root        240 S   init
    2 root            SW  [keventd]
    3 root            RWN [ksoftirqd_CPU0]
    4 root            SW  [kswapd]
    5 root            SW  [bdflush]
    6 root            SW  [kupdated]
    7 root            SW  [mtdblockd]
    8 root            SW  [tffsd_mtd3]
   10 root        240 S   init
   11 root        368 S   /bin/sh /etc/init.d/rc.S
  195 root        208 S   ledcfg -c -d -f /etc/Fritz_Box_FON.led.conf
  222 root            SW  [capitransp]
  238 root        280 S   /usr/bin/capiotcp_server -p5031 -m1
  240 root        280 S   /usr/bin/capiotcp_server -p5031 -m1
  241 root        280 S   /usr/bin/capiotcp_server -p5031 -m1
  253 root            Z N [ctlmgr]
  256 root        764 S N ctlmgr
  259 root            Z   [websrv]
  261 root        928 S N websrv
  264 root            Z   [igdd]
  266 root       1060 S   igdd
  267 root       1060 S   igdd
  268 root       1060 S   igdd
  269 root       1060 S   igdd
  270 root        928 S N websrv
  271 root        928 S N websrv
  272 root        928 S N websrv
  276 root            Z   [multid]
  278 root        908 S   multid
  284 root            Z   [dsld]
  289 root       1288 S < dsld -i -n
  301 root            Z   [telefon]
  305 root            Z   [voipd]
  306 root       1380 S < voipd
  308 root        180 S   /bin/run_clock -c /dev/tffs/mtd3 -d
  315 root            Z   [telnetd]
  316 root        228 S   /usr/sbin/telnetd
  335 root        356 S   /bin/sh /var/tmp/callmonitor.sh
  345 root        612 S   telefon
  426 root            Z   [sh]
  432 root            Z   [sh]
  560 root            Z   [sh]
  566 root            Z   [sh]
  582 root            Z   [sh]
  588 root            Z   [sh]
  618 root            Z   [sh]
  624 root            Z   [sh]
  848 root        416 S   -sh
  982 root        316 R   ps edaf

Gruß
crusader
 
ich bin mir ziemlich sicher dass die zombie shells vom nc kommen, bei mir traten mit nc -w 1 keine mehr auf. Mit dem Rest habe ich nichts zu tun, ich schwör ;-)
 
Aber sicher hast du damit zu tun. Die treten nämlich dann auf, wenn ich deine debug.cfg benutze mit:
Code:
killall telefon
telefon | /var/tmp/callmonitor.sh
Da callmonitor.sh endlos läuft, bleibt das Script hier stehen (und die debug.cfg[bzw. user.rc] bleibt offen (und meine FBF kriegt Zombies(und ich krieg die Krise)))
Wenn ich die debug.cfg ändere auf:
Code:
killall telefon
telefon | /var/tmp/callmonitor.sh &
ist mein Prozessliste auch OK:
Code:
  PID  Uid     VmSize Stat Command
    1 root        248 S   init
    2 root            SW  [keventd]
    3 root            RWN [ksoftirqd_CPU0]
    4 root            SW  [kswapd]
    5 root            SW  [bdflush]
    6 root            SW  [kupdated]
    7 root            SW  [mtdblockd]
    8 root            SW  [tffsd_mtd3]
  195 root        208 S   ledcfg -c -d -f /etc/Fritz_Box_FON.led.conf
  222 root            SW  [capitransp]
  238 root        288 S   /usr/bin/capiotcp_server -p5031 -m1
  240 root        288 S   /usr/bin/capiotcp_server -p5031 -m1
  241 root        288 S   /usr/bin/capiotcp_server -p5031 -m1
  256 root        792 S N ctlmgr
  261 root        808 S N websrv
  266 root       1100 S   igdd
  267 root       1100 S   igdd
  268 root       1100 S   igdd
  269 root       1100 S   igdd
  270 root        808 S N websrv
  271 root        808 S N websrv
  272 root        808 S N websrv
  278 root        936 S   multid
  289 root       1276 S < dsld -i -n
  306 root       1128 S < voipd
  308 root        168 S   /bin/run_clock -c /dev/tffs/mtd3 -d
  316 root        212 S   /usr/sbin/telnetd
  337 root        380 S   -sh
  413 root        392 S   -sh
  628 root        368 S   /bin/sh /var/tmp/callmonitor.sh
  637 root        560 S   telefon
  638 root        316 R   ps

Also immer schön das kleine Zauberzeichen dranhängen. Dann klappt's auch mit der mod-52.

Gruß
crusader (und 36 Zombies :twisted: )
 
OK, das hab ich eingesehen. Aber dann erklär mir bitte noch die da:

259 root Z [websrv]
264 root Z [igdd]
276 root Z [multid]
284 root Z [dsld]

Die hab ich nämlich noch nie gehabt
 
Nach meiner UNIX "Idee" entstehen Zombies wenn "Parents" den Tod ihrer Kinder nicht zur Kenntnis nehmen (wollen).
Ein Parentprozess erhält das Signal "SIGCHLD" wenn ein Child stirbt/sich beendet. "Blockiert" ein Prozess dieses Signal bleibt das Child eben als Zombie am leben.
"init" mit in der Regel Prozessid " 1" ist "parent" aller Prozesse.
( Ich kenne UNIX-Cluster z.B. Compaq Tru 64 5.1x bei denen "init" nicht "1" hat.)

Für Max-1968 würde ich nun vermuten:
- Irgend eine Art von "upload/Firmwareupdate" gestartet ?
- Das Parent von "websrv,igdd,multid,dsld" reagiert nicht korrekt
- Prozesse "hängen" nicht funktionsfähig rum.

Könnte mir vorstellen:
- systemstart ( init )
=> alles schön brav gestartet, aber "still in init.."
=> in "debug.cfg" => Prozess(e) gestartet, aber nicht im Hintergrund
=> wenn andere (Child)Prozesse sich beenden wollen/Probleme machen: kommen noch nicht wieder dran an ihr "parent", da ja noch "debug.cfg" die Kontrolle vom init hat.

Abhilfe: Prozesse ordentlich mit "&" in den Hintergrund senden, falls sie dieses nicht von sich aus, z.B. als sogenannter "daemon" tun.

Haveaniceday

PS: Hoffe die Erklärung passt und ist verständlich.
 
@Max:
Aber dann erklär mir bitte noch die da:
Prinzipielle Erklärung hat haveaniceday ja schon gegeben.
Im Detail:
-init startet eine shell, in der das Script /etc/rc.S ausgeführt wird.
-Aus rc.S werden weitere Scripts aufgerufen, als letztes rc.user (das ist die Kopie von debug.cfg).
-In rc.user wird callmonitor.sh gestartet. Die shell wartet bis zum doomsday, dass sich callmonitor beendet.
-Alle Prozesse, die vorher im rc.S-script schon mal beendet wurden, sich aber noch nicht abgemeldet hatten (SIGCHLD), können nun vom Parent (sh) nicht mehr berücksichtigt werden.

Daher:
+init-Prozess ist noch aktiv (PID 10)
+shell ist noch aktiv (PID11)
+ctlmgr ist der erste Zombie, denn in rc.net wurde ausgeführt:
Code:
# restart Ctl-Manager, wenn wstart den unique-WEP-Key setzt / RR
                * ) sleep 1
                    ctlmgr -s
                    sleep 1
                    ctlmgr
                    ;;
Andere Zombies enstehen, wenn andere Prozesse neu gestartet werden (kann auch außerhalb der Scripts passieren).
Wenn du nicht exakt die gleichen Zombies hast, dann liegt das vielleicht am FBF-Typ oder an der Konfiguration der mod52 oder so.
Übrigens: Habe jetzt permanent zwei nicht-erreichbare IPs als listener eingetragen-> bisher keine Probleme.

@haveaniceday:
Prozesse ordentlich mit "&" in den Hintergrund senden
Was ich immer sage: das Zauberzeichen nicht vergessen.
Aber da du schon mal hier bist:
Ich würde mir sowieso wünschen, die Brutalo-Methode
Code:
killall telefon
telefon > xxx &
überflüssig zu machen, indem man in der nächsten mod-Version eine Option einbaut, die das telefon gleich mit den richtigen Parametern startet.
Das Script von Max könnte man dann in /usr/local fest einbauen.

Was haltet ihr davon ?

Gruß
crusader
 
Das Skript habe ich schon und den Einbau wollte ich vornehmen.
Ich bastel im Moment noch and dem Patch für die Buildumgebung.

Jeder soll einfach die gleichen Binaries auch über das buildroot selber erstellen können.
Dazu will ich ein patchfile zu Enriks buildroot edition machen.

Haveaniceday

PS: Brutalo Methode könnte weiterhin notwendig sein. Ohne konfigurierte "Clients" soll telefon normal gestartet werden. Damit keine unbekannten Seiteneffekte auftreten,
bzw. diese einfach durch ausschalten zu beenden sind.
 
crusader schrieb:
Ich würde mir sowieso wünschen, die Brutalo-Methode
Code:
killall telefon
telefon > xxx &

Gruß
crusader

Ich lese immer wieder von Brutalo-Methode, was genau ist darunter zu verstehen .... Gefahr für den Flash, oder ..oder oder?!
 
kill und "start again" ist damit gemeint. Ist "unschön".
Ist aber ganz nomral für die meisten Windowsuser ( Orgie "restart" um die Installation zu beenden..)

Ist eher eine "akademische" Frage. Schadet nichts. geht nix kaputt. Dauert nur 1-3 Sekunden länger beim Start.

Haveaniceday
 
shame on me....:

#
# ps -edaf | fgrep -i " z "
264 root Z N [ctlmgr]
286 root Z [websrv]
291 root Z [igdd]
303 root Z [multid]
311 root Z [dsld]
328 root Z [telefon]
333 root Z [voipd]
343 root Z [telnetd]
368 root Z [crond]

Ich weiß schon was Zombies etc sind, hab irgendwann so um 1984/6 das erste Mal mit tunix in Urform zu tun gehabt und sogar mal Schulungen für "Umsteiger" gehalten... Ist nur alles ziemlich eingeschlafen :oops:

Mal was anderes... Wenn telefon ohne Umlenkung gestartet wird, landet die Ausgabe doch auf der Konsole, oder ? Kann sich nicht ein beliebiges Skript einfach die Konsole greifen und auswerten ? Dann bräuchte telefon gar nicht mehr so schmerzvoll beendet werden, wenn das in rcdingsbums ohne /dev/null gestartet wird ?
 
Status
Für weitere Antworten geschlossen.

Statistik des Forums

Themen
246,206
Beiträge
2,248,027
Mitglieder
373,770
Neuestes Mitglied
TomTom55
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.