Could this be a "deadlock"?

Asterisk Asterisk Support
1

I don’t know what a deadlock is but after some Googling I am wondering if it is my problem and looking for help.

The system is Asterisk 1.6.2.18 on an Intel i5 PC with Dahdi 2.4.0, a Xorcom 8 FXO Astribank and FreePBX 2.8.x.

The problem is about once a week the system stops receiving inbound calls (just rings) and cannot make outbound calls. The system shows 2 or 3 active calls when none exist. Amportal restart does not correct the problem It does NOT right itself until you reboot.

I checked the state of the 1st 4 dahdi channels while this was going on and the results are below. I also have a log excerpt from the time frame where the problem occurred but don’t know how to attach it. This same issue has occurred on another system I support with a Digium AEX800 and 4 FXO ports.

ecophone-xCLI> dahdi show channel 1
Channel: 1
File Descriptor: 12
Span: 1
Extension:
Dialing: no
Context: from-zaptel
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner: DAHDI/1-1
Real: DAHDI/1-1
Callwait:
Threeway:
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: yes
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
128 taps
(unless TDM bridged) currently ON
Wait for dialtone: 0ms
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook
ecophone-xCLI> dahdi show channel 2
Channel: 2
File Descriptor: 13
Span: 1
Extension:
Dialing: no
Context: from-zaptel
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner: DAHDI/2-1
Real: DAHDI/2-1
Callwait:
Threeway:
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: yes
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
128 taps
(unless TDM bridged) currently OFF
Wait for dialtone: 0ms
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook
ecophone-xCLI> dahdi show channel 3
Channel: 3
File Descriptor: 14
Span: 1
Extension:
Dialing: no
Context: from-zaptel
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner:
Real:
Callwait:
Threeway:
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
128 taps
(unless TDM bridged) currently OFF
Wait for dialtone: 0ms
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook
ecophone-xCLI> dahdi show channel 4
Channel: 4
File Descriptor: 15
Span: 1
Extension:
Dialing: no
Context: from-zaptel
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner:
Real:
Callwait:
Threeway:
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
128 taps
(unless TDM bridged) currently OFF
Wait for dialtone: 0ms
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook
ecophone-xCLI> dahdi show channel 5
Channel: 5
File Descriptor: 16
Span: 1
Extension:
Dialing: no
Context: from-zaptel
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner:
Real:
Callwait:
Threeway:
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
128 taps
(unless TDM bridged) currently OFF
Wait for dialtone: 0ms
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook
ecophone-xCLI>

2

Probably.

A deadlock is when there are two threads of execution which both have control of a resource and require control of a resource, but the resource each wants is the one that the other one has. Neither resource will ever become available.

You can actually have chains of more than two threads in a cycle.

The most common resources that get deadlocked are data structures describing, channels, etc., etc. Threads need control so that they can be updated without any confusion due to their being changed or read by something else at the same time.

3

Thanks,

I haven’t done anything to modify the source to 1.6.2.18 is it still possible to have a “deadlock”?

I know my deadlock theory is a little far fetched but this problem has been occurring on a regular basis for 2 months and I am at the end of my rope to explain it, much less fix it.

4

Deadlocks are a common problem in Asterisk. They should be designed out, but the software is sufficiently complex and so heavily dependent on locking, that many get missed. Some can require very specific circumstances.

To confirm a deadlock, you need to debug with thread debugging enabled and then start a new CLI session when it locks up and run “core show locks”. If you can find a circular dependency, you definitely have a deadlock.

A few deadlocks involve resources not controlled by this locking mechanism.

The deadlock mitigation strategies can result in repeated attempts to gain locks, which may not be so obvious.

Any deadlocks that are not fixed in 1.6.2.20 will never be fixed in 1.6.x.x.

5

Thanks again David, If you don’t mind I have one last question.

Would a deadlock cause a sip extension to become unreachable? I noticed in the logs on the last time that I caught this that as a person tried to park a call the call dropped and her extension became unreachable. Then the whole system quit sending and receiving calls.

6

It depends where the deadlock is. There is a good chance that a deadlock affecting SIP devices (not extensions) would prevent the OPTION packets for quailify being sent.