Asterisk PJSIP very slow startup and "cannot reload a module yet; request queued" error

Asterisk Asterisk SIP
1

I am running Asterisk on a Linux server using the PJSIP channel driver. When I start the Asterisk service, I use the following command:

sh /usr/sbin/safe_asterisk >/dev/null </dev/null 2>&1 &

The Asterisk process starts, but the modules take a very long time to initialize and come up. On my other servers, the startup is almost instant, but on this specific server, I have to wait a significant amount of time before the system is ready to process calls.

While the system is stuck in this starting phase, if I attach to the Asterisk CLI and attempt to force a reload using pjsip reload, the command is rejected and I get spammed with the following message in an endless loop:

ISTVATXOBAPLP01*CLI> pjsip reload
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued

What exactly triggers the “request queued” warning when attempting a reload?

2

If all the modules haven’t loaded (because it’s starting up), then you can’t reload any. Only after it has started can you reload.

Common issues for this would be networking related, such as DNS, or disk I/O, or CPU stealing, or if a database is in use then database throughput/connectivity.

3

get a backtrace if jclop suggestion does not help
https://docs.asterisk.org/Development/Debugging/Getting-a-Backtrace/
reloading when hanging would not work as you have demonstrated

On Wed, Mar 11, 2026 at 8:02 AM mfb14 <notifications@asterisk.discoursemail.com> wrote:

Someone replied to a topic you are Watching.

mfb14
March 11

I am running Asterisk on a Linux server using the PJSIP channel driver. When I start the Asterisk service, I use the following command:

sh /usr/sbin/safe_asterisk >/dev/null </dev/null 2>&1 &

The Asterisk process starts, but the modules take a very long time to initialize and come up. On my other servers, the startup is almost instant, but on this specific server, I have to wait a significant amount of time before the system is ready to process calls.

While the system is stuck in this starting phase, if I attach to the Asterisk CLI and attempt to force a reload using pjsip reload, the command is rejected and I get spammed with the following message in an endless loop:

ISTVATXOBAPLP01*CLI> pjsip reload
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued
Asterisk cannot reload a module yet; request queued

What exactly triggers the “request queued” warning when attempting a reload?

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

4

Hello,

Thank you for your answers. What I am really curious about is why the startup process takes so incredibly long. It literally took about 8-9 hours before Asterisk was finally able to process the queued pjsip reload commands! I have another Asterisk server with the exact same modules loaded, and I don’t face this issue there at all.

Here is the exact timeline of what happened. About 5 hours after starting Asterisk, it finally threw this log:

[Mar 11 05:32:30] ERROR[1420] bucket.c: Excessive refcount 100000 reached on ao2 object 0x34c2380
[Mar 11 05:32:30] ERROR[1420] bucket.c: FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object 0x34c2380 (0)
[Mar 11 05:32:30] ERROR[1420] : Got 7 backtrace records
# 0: /usr/sbin/asterisk(__ao2_ref+0x29e) [0x45e4fe]
# 1: /usr/sbin/asterisk(ast_bucket_file_alloc+0x188) [0x489538]
# 2: /usr/sbin/asterisk(ast_media_cache_init+0xb1) [0x508ec1]
# 3: /usr/sbin/asterisk() [0x43b51e]
# 4: /lib64/libc.so.6(+0x295d0) [0x7f1f8ee295d0]
# 5: /lib64/libc.so.6(__libc_start_main+0x80) [0x7f1f8ee29680]
# 6: /usr/sbin/asterisk() [0x43c86e]

[Mar 11 05:32:30] ERROR[1420] bucket.c: Excessive refcount 100000 reached on ao2 object 0x34c2380
[Mar 11 05:32:30] ERROR[1420] bucket.c: FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object 0x34c2380 (0)
[Mar 11 05:32:30] ERROR[1420] : Got 9 backtrace records
# 0: /usr/sbin/asterisk(__ao2_ref+0x29e) [0x45e4fe]
# 1: /usr/sbin/asterisk() [0x46058f]
# 2: /usr/sbin/asterisk(__ao2_find+0x2c) [0x46092c]
# 3: /usr/sbin/asterisk(ast_bucket_file_alloc+0x13a) [0x4894ea]
# 4: /usr/sbin/asterisk(ast_media_cache_init+0xb1) [0x508ec1]
# 5: /usr/sbin/asterisk() [0x43b51e]
# 6: /lib64/libc.so.6(+0x295d0) [0x7f1f8ee295d0]
# 7: /lib64/libc.so.6(__libc_start_main+0x80) [0x7f1f8ee29680]
# 8: /usr/sbin/asterisk() [0x43c86e]

Then, about 4 hours after that crash (9 hours total waiting time), I saw that it finally executed the queued reload requests:

[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip.so’.
[Mar 11 09:23:59] NOTICE[26313] sorcery.c: Type ‘system’ is not reloadable, maintaining previous values
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_authenticator_digest.so’.
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_endpoint_identifier_ip.so’.
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_mwi.so’.
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_notify.so’.
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_outbound_publish.so’.
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_publish_asterisk.so’.
[Mar 11 09:23:59] NOTICE[1420] loader.c: Executing deferred reload request for module ‘res_pjsip_outbound_registration.so’.
[Mar 11 09:23:59] WARNING[26322] pbx_config.c: users.conf is deprecated and will be removed in a future version of Asterisk
[Mar 11 09:33:08] NOTICE[26551] sorcery.c: Type ‘system’ is not reloadable, maintaining previous values

After running Asterisk, I checked the module and saw that it was loaded.

[root@ISTVATXOBAPLP01 announce]# asterisk -rx ‘module show like media_cache’
Module Description Use Count Status Support Level
res_http_media_cache.so HTTP Media Cache Backend 1 Running core
1 modules loaded

Given that my other identical server starts instantly, what else could be causing the module loader to hang for hours before reaching “Asterisk Ready”? How can I trace exactly what Asterisk is waiting for during this massive delay now?

5

Are you using HTTP sourced sound files with ephemeral URLs?

6

Yes, I use it for some cases.

7

Bucket is what is used by the media cache, so since you saw such output it may very well be that the on-disk media cache has grown quite large on that system. I don’t have much experience with it unfortunately, so someone else may be able to provide more details but I do know there are CLI commands prefixed with “media cache” to interact with it, and “media cache show all” could at least confirm that suspicion.

1 Like
8

Thanks everyone for your help! The problem is finally solved.

The tip regarding the media cache was spot on. Our system plays a large number of dynamic TTS audio files directly from HTTP URLs. It turned out that Asterisk’s res_http_media_cache.so module was saving each unique URL to AstDB (under the MediaCache family) indefinitely.

Over time, this database reached tens of thousands of entries. Initially, Asterisk tried to load them all, astobj2 reached the 100,000 refcount limit, triggering a FRACK! crash in bucket.c. This completely locked the module loader for hours, so all pjsip reload commands got stuck in a “request queued” loop.

Solution:
I cleared the bloated cache from the Asterisk CLI using the following command:
database deltree MediaCache

After that, Asterisk started instantly and the reloading problem disappeared.

Thanks again for pointing me in the right

9

i do not use any of these so i have no experience ..

there is a pr for ephemeral which solves issues like this

which version asterisk are u using ?

is there a additional case case to add ?

12

You should really check if you are hacked. Check for Crypto miners they can really destroy asterisk

13

Great Postback. Good to know you resolved your issue

1 Like
14

i think the correct way to go would be adding in media_cache.c a flag for ephemeral media URLs, should not be written to astDB

15

I have a “hack” script that cleans up recordings that are older than X amount of days. Every time I tried posting it here the syntaxing came out all messed up. I run it as a cron job every day. You can see it here http://h6315.com/media.txt. I plan on cleaning it up and having it modify the sqlite db directly and removing the file on it’s own…

16

On Thursday 12 March 2026 at 14:21:43, Dovid wrote:

I have a “hack” script that cleans up recordings that are older than X
amount of days. Every time I tried posting it here the syntaxing came out
all messed up. I run it as a cron job every day. You can see it here
http://h6315.com/media.txt. I plan on cleaning it up and having it modify
the sqlite db directly and removing the file on it’s own…

Be careful with connecting to SQLite from multiple clients simultaneously:

“SQLite does let simultaneous access happen, and there’s no reason why WAL
mode would prevent it, but the people who programmed the applications have to
have had this in mind when they wrote the software: rather than optimize each
program for speed, they have to optimize each program for leaving the database
free. This means using transactions properly: BEGIN, a short burst of
commands, then COMMIT as soon as possible.”

Antony.

–
“Remember: the S in IoT stands for Security.”

  • Jan-Piet Mens
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.