Ast1.4 Spooler steht still - Dateien werden n. verarbeitet

[HobbyStern]

Hallo Gemeinde,

ich beobachte seit einiger Zeit das einige Minuten nach einem Neustart von Asterisk Callfiles nicht mehr abgearbeitet werden - startet man dann Asterisk mit einem restart geht es manchmal - manchmal auch nicht.

Rechte stehen bei root:root , eine Änderung zu user:user und 777 hilft auch nicht. Die Dateien werden schlichtweg nicht mehr abgearbeitet, mittlerweile lasse ich ein Skript stündlich schauen ob es etwas "vegetiert" - dann restartet sich Asterisk - hilft das auch nicht wird das Callfile gelöscht.

Hat jemand Rat? Kann man ggf. den Spooler alleine neu reloaden? IMHO nicht.

Asterisk wie Sig 1.4.25.1 mit Pickup und MissedCalls Patch.

 

[Tweety]

Ich habe jetzt nicht in die entsprechenden Quellen geschaut... aber könnte vielleicht ein Problem mit dem inotify Subsystem deines Kernels vorliegen? Wenn ich so etwas in Asterisk umsetzen müsste, würde ich darauf bauen. Du kannst das mit den inotify Tools prüfen. Einfach mal das Verzeichnis überwachen lassen.

Falls da nichts bei raus kommt, würde ich mal die (Debug)Logs anschauen bzw. hier posten...

 

[HobbyStern]

Hi,

ich teste gerade die inotifywatch Funktion für "outgoing" - lass sie einfach mal ne Woche laufen...die andere Frage wäre was ich mit dem Ouput dann anfangen kann ?!

Naja - schaun wer mal. Es ist ja def. so das es manchmal geht, manchmal halt nicht ?!

LG Stefan

 

[HobbyStern]

Hey Tweety,

ich habe nun mal das inotify laufen gelassen, hier ist der debug :

[IMG]file:///D:/DOKUME%7E1/stefan/LOKALE%7E1/Temp/moz-screenshot.png[/IMG][IMG]file:///D:/DOKUME%7E1/stefan/LOKALE%7E1/Temp/moz-screenshot-1.png[/IMG]total  access  modify  attrib  close_write  close_nowrite  open  moved_to  delete  filename

370    24      7       7       31           127            158   8         8       /var/spool/asterisk/outgoing/

Vielleicht die relevanten Stellen hier :

Verzeichnis /var/spool/asterisk/outgoing/
Moved To 8
Deleted 8

Was bedeutet das für mich?
Was kann ich daraus folgern?

LG Stefan

 

[Tweety]

Das sind einfach die Statistiken des überwachten Verzeichnisses. INotify sollte daher eigentlich korrekt funktionieren (habe schon erlebt, dass der Kernel ooopste und es damit zu diversen Fehlfunktionen kam).

Falls dein Asterisk immer noch Probleme macht (wovon ich ausgehe), müsste man sich den entsprechenden Quellcode mal anschauen (insbesondere wie die Verzeichnisse überwacht werden).

 

[HobbyStern]

Nun gut, aber ich gehe eigentlich davon aus das ich Asterisk da ausklammern darf - da es ja bei anderen einwandfrei löppt...

Es ist ja auch zu beheben - durch einen Neustart des Asterisken, bzw. das Neustarten des modules zum spoolen.

*StehaufdemSchlauch*

Danke für Deine Zeit - mal so nebenbei.

LG Stefan

 

[Tweety]

Könnte auch (mal wieder) ein DeadLock sein. Hast du mal eine etwas frischere Version ausprobiert?

Ich persönlich würde aktuell 1.6.1 favorisieren!

 

[HobbyStern]

Mhmm....bin da sehr skeptisch, ich habe das Kind hier produktiv laufen - damals war 1.6.x mein Ziel, aber 1.4.x war stabil.

Ich habe noch Abhängigkeiten mit im 1.4.er die in 1.6.x noch nicht geklärt sind - der PickUp - der MissedCallsbySnom und der LED PatchbySnom (heißt aber anders)...

Ich wäre zumindest sehr vorsichtig bei 1.6

Von Foschi und Firma wurde mir vor 6 Monaten noch ein Downgrade auf 1.4.23 empfohlen worden - dort gab es dann wirklich alle Patches ohne Sorgen und Probleme.

Nutzt Du 1.6 produktiv?

LG Stefan

 

[Tweety]

Habe inzwischen 1.6.1 z.T. produktiv und bin eigentlich relativ zufrieden. Die auftretenden Bugs kommen meistens auch in 1.4 vor. Zu 1.6.2 bin ich noch nicht gekommen, aber was ich nur schnell gesehen habe, schaut noch nicht gut aus.

Missed Calls sind inzwischen integriert. Notifies für Pickups bekommst du (zumindest funktioniert der Patch bei mir und freue mich natürlich auch immer Feedback) von hier: http://www.net-performer.de/asterisk/asterisk-1.6.1-pickup-by-call-id.patch

Du wirst wohl noch den Patch brauchen (siehe auch http://www.ip-phone-forum.de/showpost.php?p=1492581&postcount=364) http://svnview.digium.com/svn/aster...view=patch&r1=248399&r2=248398&pathrev=248399

Was meinst du mit LED Patch?

Edit: Hab eben mal in die Quellen geschaut. Da wird nicht mit inotify gearbeitet...

 

[HobbyStern]

Hey,

darf ich vorweg fragen was heißt "z.T. produktiv" ? ;-)

Patches sind okay, missedcalls war IMHO Russel?!
Devstate ist ja integriert (ebenf. Russels)
PickupPatch habe ich mit Freude vernommen das nach 2 Jahren "HOWTO" nun endlich eine Integration stattfinden soll...!
Der "LED-Patch" sollte den obrigen Devstate benennen - bin heute etwas durch den Wind..

In meiner Konstellation bin ich im Moment so weit keine "hardware" mehr zu benutzen die mich an eine AstBox bindet, also es läuft alles über SIP, daher wäre es auf jeden Fall mal möglich 1.6 zu testen. Mich gruselt es nur vor den zahlreichen deprecated Meldungen

Ist die Frage ob das ganze sein muss oder ob es nicht an einer anderen - wahrscheinlichen "Rechte" Sache hapert

Mein Skript geht so vor :

Als "root" einen touch ausführen - "datei.call"
Als "root" die Datei mit den Befehlen füllen
testweise habe ich an dieser Stelle mal 777 und asterisk:asterisk gesetzt
Als "root" die Datei moven - in var/spool/asterisk/outgoing

Bleibt die Datei nun nach 60 Sekunden im Spool Verzeichnis wartet er noch mal 30 Sekunden und dann wird die Datei gelöscht.

Das passiert aktuell sehr oft.

Ich schaue gerade in pbx_spool.c - verstehe ich es richtig das das callfile erst dann gelöscht/verschoben wird wenn es abgearbeitet ist...(was ja nach 90 sek. nicht unbedingt passieren muss (retry time) ..?

enum {   
        /*! Always delete the call file after a call succeeds or the
         * maximum number of retries is exceeded, even if the
         * modification time of the call file is in the future.
         */
        SPOOL_FLAG_ALWAYS_DELETE = (1 << 0),
        /* Don't unlink the call file after processing, move in qdonedir */
        SPOOL_FLAG_ARCHIVE = (1 << 1)
};

 

[HobbyStern]

Ooops, Doppelpost aus gegebenem Anlass ... :

Asterisk braucht mehr Zeit (erinnert mich irgendwie an mein erstes Date vor 15 Jahren )

Okay, ich habe mal alle zeitindexe hochgedreht und es sieht etwa so aus :

In meinem ersten Test durchlief Asterisk 1:20 min. nach ablegen der Datei das Spoolverzeichnis, die Datei BLIEB BESTEHEN bis der Anruf glückte, erreichte man keinen dauerte es dementsprechend länger.

Beim zweiten Test brauchte Ast mal eben 2 Minuten!

Das wäre also des rätsels lösung - merh Zeit für unseren Stern!

So einfach...

LG Stefan

 

[Tweety]

darf ich vorweg fragen was heißt "z.T. produktiv" ? ;-)

Manche Systeme "draußen" laufen auf 1.6.1 und das Stabil!

Mein Skript geht so vor :

Als "root" einen touch ausführen - "datei.call"
Als "root" die Datei mit den Befehlen füllen
testweise habe ich an dieser Stelle mal 777 und asterisk:asterisk gesetzt
Als "root" die Datei moven - in var/spool/asterisk/outgoing

Bleibt die Datei nun nach 60 Sekunden im Spool Verzeichnis wartet er noch mal 30 Sekunden und dann wird die Datei gelöscht.

Das passiert aktuell sehr oft.

Dumme Frage: Was zeigen deine Logs an? Kann es vielleicht sein, dass in den Dateien manchmal Fehler enthalten sind?

Ich schaue gerade in pbx_spool.c - verstehe ich es richtig das das callfile erst dann gelöscht/verschoben wird wenn es abgearbeitet ist...(was ja nach 90 sek. nicht unbedingt passieren muss (retry time) ..?

remove_from_queue wird erst aufgerufen, wenn die Datei abgearbeitet wurde (warum auch immer)

 

[Tweety]

Aachso! Dein Skript hat die Datei gelöscht!?

 

[HobbyStern]

Dumme Frage: Was zeigen deine Logs an? Kann es vielleicht sein, dass in den Dateien manchmal Fehler enthalten sind?
remove_from_queue wird erst aufgerufen, wenn die Datei abgearbeitet wurde (warum auch immer)

Keine Fehler, keine Logeinträge. remove_from_queue ist natürlich dann sub-optimal Ist mir ja auch erst gerade klar geworden das die Callfiles die gesamte Zeit da bleiben, egal wie lange.

Aachso! Dein Skript hat die Datei gelöscht!?

Halblang! Das Skript löschte bis dato nach 3 Minuten das File, weil es schlichtweg nach meiner Erfahrung nicht verarbeitet wurde, es stapelten sich files und irgendwann wurden alle abgearbeitet (meist nach einem nice-restart mitten in der Nacht am WE, macht Freude bei den Jungs die Ihre Handys an lassen)

Ich habe nun die Zeit netter eingestellt und lasse eine halbe Stunde warten, aber IMHO sollte ich vor einem restart das outgoing directory sicherheitshalber löschen um nicht solch einer Attacke zum Opfer zu fallen...

Ich halte trotzdem mal ein Auge darauf - es gab ja einen Grund warum ich nach 3 Minuten callfiles gelöscht habe, schlichtweg weil sie nach 2 Wochen immer noch da lagen...ggf. war das was ich gerade gesehen habe nur ein "schnappschuss" der Realität.

Warten wir es ab..Danke für Deine Hilfe, Du tust viel Gutes für den Asterisken!

LG Stefan

 

[Tweety]

remove_from_queue ist natürlich dann sub-optimal

Das "warum auch immer" war auf den Parameter "status" der Funktion bezogen ;-)

Ich halte trotzdem mal ein Auge darauf - es gab ja einen Grund warum ich nach 3 Minuten callfiles gelöscht habe, schlichtweg weil sie nach 2 Wochen immer noch da lagen...ggf. war das was ich gerade gesehen habe nur ein "schnappschuss" der Realität.

Warten wir es ab..Danke für Deine Hilfe, Du tust viel Gutes für den Asterisken!

Warten wir wirklich mal ab... ich hab das Gefühl, dass der irgendwo hängt.

Danke auch!

 

[HobbyStern]

ich hab das Gefühl, dass der irgendwo hängt.

Kannst Dich beruhigen - ich auch