# \[help\]core reload deadlocks Asterisk **URL:** \ **Category:** Reporting an Issue\ **Created:** [July 9, 2026, 12:59am UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352 "2026-07-09T00:59:06Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![norman\_namkoong](https://forums.vitalpbx.org/user_avatar/forums.vitalpbx.org/norman_namkoong/32/270_2.png) [@norman\_namkoong](https://forums.vitalpbx.org/u/norman_namkoong)\ **Post date:** [July 9, 2026, 12:59am UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/1 "2026-07-09T00:59:06Z")
hi all, who knows this bug # [bug]: core reload deadlocks Asterisk (pjsip, CLI, etc.) > > > \### 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 \, 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 \, 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 \, 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 \, 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 \, 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 \, 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 \) at asterisk.c:1478 > \#31 0x00005581856756dc in dummy\_start (data=0x7f3c1812deb0) at utils.c:1643 > \#32 0x00007f3c482a71f5 in start\_thread (arg=\) 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 1. cli\>core relaod 2. asterisk hang 3. I thnik pjsip stop 4. must asterisk restart wil be ok I am not sure where come from this issue ---
**Author:** ![miguel](https://forums.vitalpbx.org/user_avatar/forums.vitalpbx.org/miguel/32/415_2.png) [@miguel](https://forums.vitalpbx.org/u/miguel)\ **Post date:** [July 9, 2026, 1:00am UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/2 "2026-07-09T01:00:10Z")
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` ---
**Author:** ![norman\_namkoong](https://forums.vitalpbx.org/user_avatar/forums.vitalpbx.org/norman_namkoong/32/270_2.png) [@norman\_namkoong](https://forums.vitalpbx.org/u/norman_namkoong)\ **Post date:** [July 9, 2026, 2:21am UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/3 "2026-07-09T02:21:08Z")
thanks for reply, i try “vitalpbx optimize-server” and try again, but it happens again. ---
**Author:** ![norman\_namkoong](https://forums.vitalpbx.org/user_avatar/forums.vitalpbx.org/norman_namkoong/32/270_2.png) [@norman\_namkoong](https://forums.vitalpbx.org/u/norman_namkoong)\ **Post date:** [July 9, 2026, 2:49am UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/4 "2026-07-09T02:49:13Z")
it fix for me noload =\> res\_pjsip\_config\_wizard.so reboot It works (core reload) ---
**Author:** ![mohamed.soliman](https://forums.vitalpbx.org/letter_avatar_proxy/v4/letter/m/85e7bf/32.png) [@mohamed.soliman](https://forums.vitalpbx.org/u/mohamed.soliman)\ **Post date:** [July 9, 2026, 11:22am UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/5 "2026-07-09T11:22:43Z")
Where we add this line noload =\> res\_pjsip\_config\_wizard.so in **/etc/asterisk/asterisk.conf**?? ---
**Author:** ![maynor](https://forums.vitalpbx.org/letter_avatar_proxy/v4/letter/m/3e96dc/32.png) [@maynor](https://forums.vitalpbx.org/u/maynor)\ **Post date:** [July 9, 2026, 2:45pm UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/6 "2026-07-09T14:45:40Z")
You can add it to the following file: `/etc/asterisk/vitalpbx/modules__20-noload.conf` ---
**Author:** ![intelesync](https://forums.vitalpbx.org/user_avatar/forums.vitalpbx.org/intelesync/32/69_2.png) [@intelesync](https://forums.vitalpbx.org/u/intelesync)\ **Post date:** [July 16, 2026, 12:47pm UTC](https://forums.vitalpbx.org/t/help-core-reload-deadlocks-asterisk/6352/7 "2026-07-16T12:47:01Z")
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.