Dahdi Scheduler Error

I get the following error repeating. This has happened 4 times in the month and a half or two months I have had this server running. When it happens you get no outbound or inbound calls but it doesn’t crash asterisk. I believe (though I only got to test this one of the times) that the t1 does not go into alarm when this happens. Any ideas on how to fix it?

Asterisk1CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: Asked to deelete sched id -1
Asterisk1
CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: No more room in scheduler
Asterisk1CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: No more room in scheduler
Asterisk1
CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: Asked to deelete sched id -1
Asterisk1CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: No more room in scheduler
Asterisk1
CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: No more room in scheduler
Asterisk1CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: Asked to deelete sched id -1
Asterisk1
CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: No more room in scheduler
Asterisk1CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: No more room in scheduler
Asterisk1
CLI> [Jun 29 08:28:45] ERROR[30640]: chan_dahdi.c:10515 dahdi_pri_error: Asked to deelete sched id -1

I am also getting this same issue in Asterisk v1.6.1.1 and Dahdi 2.2.0 (also occured in 1.6.1.0 and earlier Dahdi)

[Jul 7 02:27:59] ERROR[2630] chan_dahdi.c: No more room in scheduler
[Jul 7 02:27:59] ERROR[2630] chan_dahdi.c: Asked to delete sched id -1???

This has been happening intermittently about once a week and for some unknown reason seems to always occur at 02:27 ± 5mins (except for one occurrence). This is occurring on two intendant servers with different hardware (except both have a Digium Wildcard TE110P T1/E1 Board)

Restarting asterisk clears.

Has anyone any idea what is going on here?

Ratinox,
I have been talking to Digium about this and they have so far told me to update Dahdi and Asterisk to 2.2.0 and 1.6.0.10 respectively. I tried to update dahdi on my backup server and so far haven’t been able to get it to compile. They are going to ssh in and take a look themselves. I’ll keep you posted on what I find

We are also using TE110P and dell 2650 servers what server are you running on

This happens both on a dell and a hand built intel chassis server, after investigating further this is happening to us every Tuesday am we currently suspect our provider NTL are doing something to our lines at this time. Is there any regular pattern to your failures?

not that I can tell except that it generally happens when I’m not at work like on a weekend or sometimes overnight. It happened last on the 5th of July the log file got corrupted so I don’t know the exact time and I wasn’t logging cli up to that point. I now run putty on the cli all day every day and watch for it. I will have another log the next time it does it.

do you know where internally asterisk logs output from CLI?

in /var/log/asterisk/messages

messages.0 .1 etc will be older logs

you can configure how much gets logged in logger.conf

messages => notice,warning,error

is normal

messages => notice,warning,error,debug,verbose

is what I use for debugging, but file gets very big!

after changing logger.conf do a “logger reload” under the cli

Did you find out what was the problem?
I am experiencing exactly the same… :frowning:
Asterisk 1.4.26.1
DAHDI 2.2.0.2
Libpri 1.4.10.1

Received this confirmation from Virgin/NTL (our provider) they are performing tests weekly on a Tuesday at 2-3am, I have turned off CRC4 in the config but the issue remains, will ask them to try switching this off their end. In the mean time I have added a scheduled shell script to check for the scheduler errors in the Asterisk messages log and restart Asterisk when they occur.

“See logs below, logs confirm that REX test was in operation on PDTC 22 at this time, however there are several other customers on this PDTC that suffer no problems at all. Please go back to customer and request that they look at their setup and go over their settings, the switch has to work to several interfaces and is therefore not able to individually be specified for just one customer, the customer may not for instance require CRC4 checking, this is something that we could turn off to see if their switch is over sensitive to this.”

We recently updated asterisk from version 1.6.0.5, dahdi 2.1.0.2 (where we were not having scheduler problems) to version 1.6.1.4 and dahdi 2.2.0.2. We are running a Dell poweredge 850 with a TE122 Digium card. Right after we upgraded we starting noticing these dahdi scheduler errors as well as some echo issues with our TE122 card. We called Digium and they did some work in order to fix the echo problems with some luck. We then decided to downgrade dadhi back to 2.1.0.2 to see if this would solve both problems… After the downgrade (two weeks ago) we though our problems were solved but this morning we realized they were not. We had our asterisk logs set to the following and it didn’t record the dahdi scheduler errors:

console => notice,warning,error
messages => verbose

Browsing through the logs I can determine where dahdi started throwing errors, we were making calls one minute and not able to the next, but the most troubling thing is I can’t tell why… Hope this information helps.

Nathan

I think the key thing here is to identify if there is a pattern to the errors, if as in my case they are regular then its probable that they are caused by scheduled maintenance tests carried out by your provider (ours denied this for over two months until the right person at the provider got involved).

I called my provider (LogixCommunications) and they assured me that nothing was ran on our circuit this morning. As for distinguishing a pattern, I haven’t logged the times of the other 2 occurrences but I will continue to monitor it so that I can determine if there is some type of repeating pattern to this.

Nathan

We have this problem and Digium confirmed it to be a bug… They have released a patch for it so i would recommend contacting them if you have this problem. The problem it seems lies in the libpri portion of asterisk. So you’ll have to patch libpri and then compile from source.

In the meanwhile this is what we had done until asterisk provided the patch.

  1. Download logdog from caspian.dotconf.net/menu/Software/LogDog/

  2. Install Logdog by running the make install command from within the directory as in the INSTALL/README document.
    3)Configure syslog (/etc/syslog.conf) with the line (*.info | /var/log/fifo.logdog)…Leave out the brackets ofcourse.

  3. configure Asterisk to syslog by going to /etc/asterisk/logger.conf and uncommenting the line syslog.local0 => warning, notice,error.

  4. create a linux shell script to reboot asterisk (touch /etc/rebootasterisk.sh). i used the following 2 lines
    #!/bin/bash
    asterisk -rx "restart gracefully"
    Don’t forget to run chmod +x to make the shell script executable.

  5. Configure /etc/logdog.conf by opening it in your favourite text editor and scrolling down to just below the entries like Email => or Page => and create another one called RBAsterisk and point it to the shell script you created.
    RBAsterisk => /etc/rebootasterisk.sh

  6. Now scroll down to the monitors section in the same file and add the line
    No more room for scheduler => RBAsterisk

  7. Start logdog as a daemon or create a startup script so you don’t have to do it…

The best part that i like about this is it allows us to add any error code/ error message and do a specific task…

Good luck guys…

Where could I get this patch from?

Contact Digium Technical Support