Task processor stasis/p:manager:core orphaned after console reload in Asterisk 22.5

Asterisk Asterisk Support
1

Hello,

I’m experiencing different behavior between Asterisk 18 and Asterisk 22 regarding task processors.

Asterisk 18.12.x (working correctly):

  • Execute “reload” in console (asterisk -rvvv)
  • No new stasis/p:manager:core-* task processors are created
  • Command: core show taskprocessors | grep “stasis/p:manager:core”
  • Result: No orphaned task processors

Asterisk 22.5 (unexpected behavior):

  • Execute “reload” in console (asterisk -rvvv)
  • A new stasis/p:manager:core-XXXXXXXX task processor is created
  • The task processor remains in the list even after the console disconnects
  • Command: manager show connected → shows 0 users connected
  • But: core show taskprocessors | grep “stasis/p:manager:core” → shows orphaned task processors
  • These orphaned task processors accumulate over time, causing pool-control queue to reach limits

Questions:

  1. Is this behavior in Asterisk 22 expected/normal?
  2. If it’s a bug, is there a known fix or workaround?
  3. Should I report this as a bug in the issue tracker?

Impact:

  • After multiple reload commands, we accumulate dozens of orphaned task processors
  • stasis/pool-control queue reaches 500+ scheduled tasks
  • System requires restart to clean up

Environment:

  • Asterisk 22.5
  • Linux (Debian)
  • Default configuration

Has anyone else experienced this? Any suggestions?

Thanks!

2

I do not believe it should behave like this. I see no issue for it currently, so an issue should be filed.

3

i can not replicate the issue on latest master 20.16 not 22.XX but by me only showing up

[root@pbx07 ~]# asterisk -rx " core show taskprocessors"|grep manager
stasis/m:manager:core-0000000d 16105300 0 16404 2700 3000

4

I think it’s the users.conf support in pbx_config. If you don’t have a users.conf file, then it won’t happen. The users.conf support was removed in 23 and master.

5

@jcolp: Excellent diagnosis! The users.conf was indeed the culprit.

Test Results:

Before removing users.conf:

  • Task processors: 64 stasis/p:manager:core-* entries
  • After each “reload” command: +1-2 orphaned task processors
  • pool-control queue reaching 1700+ tasks

After removing users.conf:

  • Renamed: /etc/asterisk/users.conf → users.conf.disabled
  • Restarted Asterisk
  • Executed 10 consecutive “reload” commands
  • Result: Task processor count remained at 0
  • No new stasis/p:manager:core-* entries created

@benphone: Thanks for testing on Asterisk 20.16! Your confirmation that the issue doesn’t exist there helped narrow down the problem.