[help]core reload deadlocks Asterisk

norman_namkoong · July 9, 2026, 12:59am

hi all,

who knows this bug

[bug]: core reload deadlocks Asterisk (pjsip, CLI, etc.)

github.com/asterisk/asterisk

[bug]: core reload deadlocks Asterisk (pjsip, CLI, etc.)

opened 09:19AM - 07 Apr 26 UTC

closed 05:03PM - 08 Apr 26 UTC

Innosoft1

bug support-level-core

### Severity Major ### Versions 20.18.2 ### Components/Modules res_pjsip, r…es_pjsip_config_wizard ### Operating Environment Debian 12.13 ### Frequency of Occurrence Occasional ### Issue Description After upgrading to 20.18.2, we observed the Asterisk CLI freezing and pjsip stopping to process SIP packets while invoking "core reload". This happened on two different Asterisk instances with different network setups within a week. core reload reloads res_pjsip_config_wizard which refreshes the transport states and gets stuck waiting for a lock. I see that other threads are waiting for core reload to finish but I don't know why or for which lock core reload is waiting for. I've read several possibly, similiar issues but there are no network/DNS issues on both VMs which run on different hardware. Our transport config is minimalistic and does not use any invalid syntax. allow_reload defaults to false. ``` [transport-udp] type = transport protocol = udp bind = 1.2.3.4:5160 [transport-tcp] type = transport protocol = tcp bind = 1.2.3.4:5160 [transport-tls] type = transport protocol = tls bind = 1.2.3.4:5161 cert_file = /etc/letsencrypt/live/domain.com/fullchain.pem priv_key_file = /etc/letsencrypt/live/domain.com/privkey.pem method = tlsv1_2 ``` We had issues with pjsip freezing (not processing any packets until Asterisk was restarted) on earlier version of Asterisk 20 but those happened very sporadic like every 2-3 months. We mitigated those by restarting Asterisk every 2-3 weeks and implementing a monitoring task which kills Asterisk if it stops processing OPTIONS packets and does not process CLI commands anymore. I saw there is a patch which improves the handling of temp transport states (Commit 7226577) in Asterisk 20.19 but I'm not sure if our issue has anything to do with it. I attached a redacted coredumper output of both coredumps: [core-asterisk-2026-04-02T10-10-30Z-brief.txt](https://github.com/user-attachments/files/26532467/core-asterisk-2026-04-02T10-10-30Z-brief.txt) [core-asterisk-2026-04-02T10-10-30Z-full.txt](https://github.com/user-attachments/files/26532468/core-asterisk-2026-04-02T10-10-30Z-full.txt) [core-asterisk-2026-04-02T10-10-30Z-info.txt](https://github.com/user-attachments/files/26532469/core-asterisk-2026-04-02T10-10-30Z-info.txt) [core-asterisk-2026-04-05T02-03-35Z-brief.txt](https://github.com/user-attachments/files/26532466/core-asterisk-2026-04-05T02-03-35Z-brief.txt) [core-asterisk-2026-04-05T02-03-35Z-full.txt](https://github.com/user-attachments/files/26532470/core-asterisk-2026-04-05T02-03-35Z-full.txt) [core-asterisk-2026-04-05T02-03-35Z-info.txt](https://github.com/user-attachments/files/26532471/core-asterisk-2026-04-05T02-03-35Z-info.txt) Both instances handle little SIP traffic. When the coredumps happened, there was almost no SIP traffic (1 and 0 active calls). TIA for any feedback. ### Relevant log output ```shell #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f3c06677850) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f3c06677850, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87 #2 0x00007f3c482a3f7b in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f3c06677850, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007f3c482a65d8 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f3c066777f0, cond=0x7f3c06677828) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x7f3c06677828, mutex=0x7f3c066777f0) at ./nptl/pthread_cond_wait.c:618 #5 0x00005581855a0db7 in __ast_cond_wait (filename=0x558185747e80 "taskpool.c", lineno=658, func=0x5581857483d0 <__PRETTY_FUNCTION__.12> "__ast_taskpool_push_wait", cond_name=0x55818574812f "&sync_task.cond", mutex_name=0x55818574811f "&sync_task.lock", cond=0x7f3c06677828, t=0x7f3c066777f0) at lock.c:620 #6 0x000055818565b7ab in __ast_taskpool_push_wait (pool=0x5581a79560c0, task=0x7f3c0767eb4b <destroy_sip_transport_state>, data=0x7f3bcc3b5bc0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=440, function=0x7f3c076bd070 <__PRETTY_FUNCTION__.86> "sip_transport_state_destroy") at taskpool.c:658 #7 0x00007f3c07671c26 in __ast_sip_push_task_wait (serializer=0x0, sip_task=0x7f3c0767eb4b <destroy_sip_transport_state>, task_data=0x7f3bcc3b5bc0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=440, function=0x7f3c076bd070 <__PRETTY_FUNCTION__.86> "sip_transport_state_destroy") at res_pjsip.c:2141 #8 0x00007f3c07671cac in __ast_sip_push_task_wait_servant (serializer=0x0, sip_task=0x7f3c0767eb4b <destroy_sip_transport_state>, task_data=0x7f3bcc3b5bc0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=440, function=0x7f3c076bd070 <__PRETTY_FUNCTION__.86> "sip_transport_state_destroy") at res_pjsip.c:2153 #9 0x00007f3c0767ec46 in sip_transport_state_destroy (obj=0x7f3bcc3b5bc0) at res_pjsip/config_transport.c:440 #10 0x00005581854d2385 in __ao2_ref (user_data=0x7f3bcc3b5bc0, delta=-1, tag=0x0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=450, func=0x7f3c076bd090 <__PRETTY_FUNCTION__.85> "internal_state_destroy") at astobj2.c:615 #11 0x00005581854d26d1 in __ao2_cleanup_debug (obj=0x7f3bcc3b5bc0, tag=0x0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=450, function=0x7f3c076bd090 <__PRETTY_FUNCTION__.85> "internal_state_destroy") at astobj2.c:673 #12 0x00007f3c0767ecd2 in internal_state_destroy (obj=0x7f3bcca626e0) at res_pjsip/config_transport.c:450 #13 0x00005581854d2385 in __ao2_ref (user_data=0x7f3bcca626e0, delta=-1, tag=0x0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=659, func=0x7f3c076bd200 <__PRETTY_FUNCTION__.71> "_dtor_temp_state") at astobj2.c:615 #14 0x00005581854d26d1 in __ao2_cleanup_debug (obj=0x7f3bcca626e0, tag=0x0, file=0x7f3c076bbff7 "res_pjsip/config_transport.c", line=659, function=0x7f3c076bd200 <__PRETTY_FUNCTION__.71> "_dtor_temp_state") at astobj2.c:673 #15 0x00007f3c07681077 in _dtor_temp_state (v=0x7f3c06677db0) at res_pjsip/config_transport.c:659 #16 0x00007f3c0768101b in transport_apply (sorcery=0x5581a6af8970, obj=0x7f3bcca62d28) at res_pjsip/config_transport.c:659 #17 0x000055818562af07 in ast_sorcery_objectset_apply (sorcery=0x5581a6af8970, object=0x7f3bcca62d28, objectset=0x7f3bcc01c420) at sorcery.c:1721 #18 0x00007f3c076de5d6 in sorcery_config_internal_load (data=0x5581a779f008, sorcery=0x5581a6af8970, type=0x5581a779e930 "transport", reload=1) at res_sorcery_config.c:413 #19 0x00007f3c076de925 in sorcery_config_reload (data=0x5581a779f008, sorcery=0x5581a6af8970, type=0x5581a779e930 "transport") at res_sorcery_config.c:457 #20 0x0000558185629248 in sorcery_wizard_load (obj=0x5581a779e8a0, arg=0x7f3c066782d0, flags=0) at sorcery.c:1337 #21 0x00005581856297fc in sorcery_object_load (obj=0x5581a779e930, arg=0x7f3c066782d0, flags=2) at sorcery.c:1421 #22 0x00005581854d3fcf in internal_ao2_traverse (self=0x5581a6af9a08, flags=OBJ_NODATA, cb_fn=0x558185629599 <sorcery_object_load>, arg=0x7f3c066782d0, data=0x0, type=AO2_CALLBACK_DEFAULT, tag=0x0, file=0x558185740c83 "sorcery.c", line=1482, func=0x558185741e00 <__PRETTY_FUNCTION__.96> "ast_sorcery_reload") at astobj2_container.c:328 #23 0x00005581854d4295 in __ao2_callback (c=0x5581a6af9a08, flags=OBJ_NODATA, cb_fn=0x558185629599 <sorcery_object_load>, arg=0x7f3c066782d0, tag=0x0, file=0x558185740c83 "sorcery.c", line=1482, func=0x558185741e00 <__PRETTY_FUNCTION__.96> "ast_sorcery_reload") at astobj2_container.c:414 #24 0x0000558185629f21 in ast_sorcery_reload (sorcery=0x5581a6af8970) at sorcery.c:1482 #25 0x00007f3c076518cb in reload_module () at res_pjsip_config_wizard.c:1307 #26 0x000055818559c472 in ast_module_reload (name=0x0) at loader.c:1796 #27 0x0000558185540cd7 in handle_core_reload (e=0x5581857c2c10 <cli_cli+2000>, cmd=-4, a=0x7f3c066783e0) at cli.c:340 #28 0x000055818554a9d4 in ast_cli_command_full (uid=1001, gid=1001, fd=16, s=0x7f3c066786c0 "core reload") at cli.c:3136 #29 0x000055818554ab74 in ast_cli_command_multiple_full (uid=1001, gid=1001, fd=16, size=12, s=0x7f3c06678b1f "core reload") at cli.c:3163 #30 0x00005581854c8b30 in netconsole (vconsole=0x5581857ea9c0 <consoles>) at asterisk.c:1478 #31 0x00005581856756dc in dummy_start (data=0x7f3c1812deb0) at utils.c:1643 #32 0x00007f3c482a71f5 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 #33 0x00007f3c483278dc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 ``` ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

core : 4.5.3-7
asterisk : Asterisk 20.19.0
linux : Debian 12.14

cli>core relaod
asterisk hang
I thnik pjsip stop
must asterisk restart wil be ok

I am not sure where come from this issue

miguel · July 9, 2026, 1:00am

It says that happens on v20.18.2, and you are running 20.19.0.

In any case, I would suggest running the command below out of working hours:
vitalpbx optimize-server

norman_namkoong · July 9, 2026, 2:21am

thanks for reply,

i try “vitalpbx optimize-server”

and try again, but it happens again.

norman_namkoong · July 9, 2026, 2:49am

it fix for me

noload => res_pjsip_config_wizard.so

reboot

It works (core reload)

mohamed.soliman · July 9, 2026, 11:22am

Where we add this line
noload => res_pjsip_config_wizard.so

in /etc/asterisk/asterisk.conf ??

maynor · July 9, 2026, 2:45pm

You can add it to the following file: /etc/asterisk/vitalpbx/modules__20-noload.conf

intelesync · July 16, 2026, 12:47pm

I think we saw this a few days ago, when we were blown up by customers saying phones not working. All lights were on but nobody was home. Extensions were not registering. Rather than sitting around for hours troubleshooting, started with a simple reboot and all went to normal. Have no desire or time at the moment to help VitalPBX find this problem, just commenting here to say we noticed too.