Asterisk hängt ggf. durch vollgelaufenes log-File?

[kvogelsa]

[Edit foschi: Aussagekräftigen Titel hinzugefügt - bitte Forenregeln beachten!]

Hallo ersteinmal an dies nette Forum.

Bisher konnte ich mit google und vor allem der Suchfunktion hier alle Probs lösen, nun aber nicht mehr.

Ich verwende einen mittel-alten Rechner mit 1GHz al Telefonanlage. Installiert ist asterisk mit bristuff, zwei HFC-Karten, eine TE, eine NT. System ist Debian-Sarge.

Die TE hängt am NTBA von netcologne (unser kölner T-Com Ersatz).

An der NT hängen ISDN Telefone.

Das ganze funtkioniert im wesentlichen fehlerfrei.

Nur manchmal kann man nicht mehr raustelefonieren. Es kommt die Meldung ""Congestion" und im Telefon hat man das Besetztzeichen. Und: Nein es kann nicht sein, dass die Gegenstelle einfach besetzt ist, habe mein Handy angerufen.

Das Problem tritt auf von den ISDN Telefonen und auch von den IAX-Telefonen/Softphones, die wir betreiben.

Wir sind dabei aber weiterhin uneingeschränkt erreichbar.

Das Problem lässt sich nur durch ein "restart now" lösen, und ist dann weg. Aber es kommt wieder.

Läuft vielleicht irgendwo ein logfile voll oder so was?

Vielen Dank für Eure Hilfe.

 

[kombjuder]

Das Problem lässt sich nur durch ein "restart now" lösen, und ist dann weg. Aber es kommt wieder.

Ich schiesse Asterisk morgens um 4 über einen cronjob ab und starte ihn dann neu. Seither ist Ruhe damit.

 

[kvogelsa]

Ich schiesse Asterisk morgens um 4 über einen cronjob ab und starte ihn dann neu. Seither ist Ruhe damit.

Wenn es hilft, dann werde ich es auch so machen. Aber das kann doch keine Lösung sein...

Ist denn mal jemand dem Problem auf den Grund gegangen?

Haben alle dieses Problem?

 

[divB]

Also mir wäre das noch nie aufgefallen und hoffe nicht dass es sowas bei mir gibt

Lässt sich das in irgendeiner Weise reproduzieren oder eingrenzen (Zeit, ...)

 

[kvogelsa]

Leider nicht. Wenn das Problem auftritt, dann muss ich schnellstens den restart durchführen, damit meine Leute telefonieren können.

Wenn ich denen erzähle, ich müsse erst noch Fehlersuche betreiben, kriege ich das Kreuz ausgehängt ;-)

Ich habe jetzt auch diesen Cronjob eingerichtet. Wenn es hilft, is ja eigentlich gut. Aber es stinkt mir trotzdem...

 

[kombjuder]

Ich habe jetzt auch diesen Cronjob eingerichtet. Wenn es hilft, is ja eigentlich gut. Aber es stinkt mir trotzdem...

Ist mir in einem halben Jahr zweimal passiert. Natürlich jedesmal wenn ich unterwegs war.
Bevor es ein drittes mal passiert habe ich lieber einen Cron-Job installiert.
In den letzten eineinhalb Jahren hatte ich nicht einen Hänger.

 

[vWalter]

durch nächtliches Rebooting hab ich auch einigermassen Ruhe.
Auf einer Maschine bekomme ich manchmal aber solch nette Sachen im Log "WARNING[5302] channel.c: Avoided initial deadlock for '0x81bd680', 10 retries!" - Dann ist's meist nur eine Frage der Zeit, bis die internen ISDN-Phones nicht mehr raustelefonieren koennen.

- Ich hab fuer den Fall eine spezielle interne Nummer, mit der * nach Countdown von 10s neustartet (explodiert oder sonstwie in die Luft gegangen ist er dabei noch nie ) .

Gruss Walter



.

 

[kvogelsa]

Das ist eine gute Idee, kannst Du den enstprechenden code-snip aus der extensions.conf posten?

Vielen Dank

 

[vWalter]

Das ist eine gute Idee, kannst Du den enstprechenden code-snip aus der extensions.conf posten?

Vielen Dank

wenn's hilft, bitte schoen

aus der extensions.ael (ich nutze die conf nicht)

context interne_telefone {

...

12345678910 => {
	Answer();
	Playback(digits/9);
	Playback(digits/8);
	Playback(digits/7);
	Playback(digits/6);
	Playback(digits/5);
	Playback(digits/4);
	Playback(digits/3);
	Playback(digits/2);
	Playback(digits/1);
	Playback(digits/0);
	DeadAGI(reboot.sh);
	Hangup();
	};
}

reboot.sh ist im agi-Dir. Es ist ein ultra-simples Shell-Script :

#! /bin/sh
#
reboot

Das ganze koennte man auch ueber einen System-Aufruf machen, die DeadAGI-Variante sollte aber besser fuer den * sein, da zumindest erst noch aufgelegt wird.


Gruss
Walter



.

 

[Guard-X]

Ich werfe hier mal folgendes in den Raum: Wenn der Asterisk richtig konfiguriert ist, wird er sich nie aufhängen oder abstürzen. Außer es werden bestimmte Systemgrenzen überschritten...

:meinemei:

 

[divB]

ui, ui, ui, eine gewagte Aussage ;-)

 

[kvogelsa]

Ich werfe hier mal folgendes in den Raum: Wenn der Asterisk richtig konfiguriert ist, wird er sich nie aufhängen oder abstürzen. Außer es werden bestimmte Systemgrenzen überschritten...

:meinemei:

Da stimme ich Dir gerne zu. Ich nehme auch gern Deinen Rat entgegen, wie ich es verhindere.

Wenn Du zu oben geschildertem Problem eine Lösung weißt oder noch infos brauchst, gerne..

 

[Guard-X]

OK. Dann bitte mal ein paar Debugs erstellen. Mal sehen, was zum Zeitpunkt des Fehlers so los war...

mfg Guard-X

 

[kvogelsa]

hi guard!

jetzt hatte ich den fehler gerade mal. die CLI meldet:

-- Starting simple switch on 'Zap/2-1'
-- Accepting overlap voice call from '10' to '11' on channel 0/2, span 1
-- Executing SetCallerID("Zap/2-1", "93119850") in new stack
-- Executing Dial("Zap/2-1", "Zap/g2/01772606334||rT") in new stack
Mar 16 15:59:31 NOTICE[4779]: app_dial.c:1059 dial_exec_full: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)
== Everyone is busy/congested at this time (1:0/1/0)
== Auto fallthrough, channel 'Zap/2-1' status is 'CONGESTION'
-- Channel 0/2, span 1 got hangup request
-- Hungup 'Zap/2-1'

 

[vWalter]

Typisch ! Genau so hab ich's auf einer Maschine auch, allerdings parallel dazu auch Deadlocks in den Messages - dann hat sich die Cowntdown-Variante des Neustarts(wird auch genutzt bei Verdacht auf ein Problem - die Leute dort gucken ja nicht staendig auf ein CLI) als "lustig" etabliert, Beschwerden kommen keine.


Gruss
Walter

 

[kvogelsa]

#! /bin/sh
#
reboot

ähm!
Der Aufruf des Skriptes geht laut Ausgabe auf der CLI. Aber die Kiste rebootet nicht...:

-- Starting simple switch on 'Zap/2-1'
-- Accepting overlap voice call from '10' to '11' on channel 0/2, span 1
-- Executing SetCallerID("Zap/2-1", "93119850") in new stack
-- Executing Dial("Zap/2-1", "Zap/g2/01772606334||rT") in new stack
Mar 16 15:59:31 NOTICE[4779]: app_dial.c:1059 dial_exec_full: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)
== Everyone is busy/congested at this time (1:0/1/0)
== Auto fallthrough, channel 'Zap/2-1' status is 'CONGESTION'
-- Channel 0/2, span 1 got hangup request
-- Hungup 'Zap/2-1'

 

[vWalter]

#! /bin/sh
#
reboot

ähm!
Der Aufruf des Skriptes geht laut Ausgabe auf der CLI. Aber die Kiste rebootet nicht...:

hmmm, ich nehme dann mal an, dass Du * nicht als root laufen laesst und der User, unter dessen Namen die Kiste rennt keine REBOOT-Rechte hat .....


Gruss
Walter

 

[kvogelsa]

hmmm, ich nehme dann mal an, dass Du * nicht als root laufen laesst und der User, unter dessen Namen die Kiste rennt keine REBOOT-Rechte hat .....


Gruss
Walter

ähm, nein.

ich starte asterisk mittels fcron-job bei systemstart, aber als root.

/usr/sbin/safe_asterisk

wenn ich den asterisk genauso händisch starte, dann klappt dass rebooten...

 

[divB]

Ja, natürlich, weil du manuell vermutlich das "-U asterisk" vergisst.

Am besten du richtest mittels sudo für den Benutzer Asterisk die Rechte ein, reboot ausführen zu dürfen (man sudo, man sudoers)

 

[kvogelsa]

aber der fcron-job wird doch auch als root ausgeführt, auch ohne das -U tag...