starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 15:05:57 +03:00

[GH-ISSUE #2262] New Scheduled Tasks Stuck at "Waiting for task creation on agent" — Existing Tasks Still Working Normally #3350

New issue

Open

opened 2026-03-14 07:11:04 +03:00 by kerem · 4 comments

kerem commented

2026-03-14 07:11:04 +03:00

Owner

Originally created by @Cereal-Killa on GitHub (Jul 18, 2025).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2262

Server Info (please complete the following information):

OS: Ubuntu 22.04.5 LTS
Browser: Chrome
RMM Version (as shown in top left of web UI): Tactical RMMv1.2.0

Installation Method:

Standard
Standard with --insecure flag at install
Docker

Agent Info (please complete the following information):

Agent version (as shown in the 'Summary' tab of the agent from web UI): Agent v2.9.1
Agent OS: Windows Server 2025 Standard, 64 bit v24H2 (build 26100.4652)

Describe the bug
I have a server that appears fully online and functional in Tactical RMM. I can remote into it, view status updates, and previously created scheduled tasks continue to work and report correctly.

However, I recently created two new scheduled tasks this week. They’ve been stuck for over 3 days with the message:
"Waiting for task creation on agent"

Existing tasks continue to function. Only the new ones are affected. The agent is responsive and shows no signs of failure.

To Reproduce
Steps to reproduce the behavior:

Go to an online, functional agent
Create a new scheduled task (script, command, etc.)
Wait and monitor task status
Task remains in "Waiting for task creation on agent" state indefinitely

Expected behavior
New tasks should be created and registered on the agent, just like existing ones that are still functioning.

Screenshots

Additional context

Performed agent repair and agent recovery
No errors visible in web UI
Agent status is "online" with working remote access and check-ins
Two older tasks are still functional and updating status correctly
New tasks do not get created or pushed to the agent

Is there a known issue with agent task queues or task sync mechanisms that could cause this?

Let me know if you'd like a version with logs attached or to help investigate possible causes.

Originally created by @Cereal-Killa on GitHub (Jul 18, 2025). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2262 **Server Info (please complete the following information):** - OS: Ubuntu 22.04.5 LTS - Browser: Chrome - RMM Version (as shown in top left of web UI): Tactical RMMv1.2.0 **Installation Method:** - [x] Standard - [ ] Standard with `--insecure` flag at install - [ ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): Agent v2.9.1 - Agent OS: Windows Server 2025 Standard, 64 bit v24H2 (build 26100.4652) **Describe the bug** I have a server that appears fully online and functional in Tactical RMM. I can remote into it, view status updates, and previously created scheduled tasks continue to work and report correctly. However, I recently created two new scheduled tasks this week. They’ve been stuck for over 3 days with the message: "Waiting for task creation on agent" Existing tasks continue to function. Only the new ones are affected. The agent is responsive and shows no signs of failure. **To Reproduce** Steps to reproduce the behavior: 1. Go to an online, functional agent 2. Create a new scheduled task (script, command, etc.) 3. Wait and monitor task status 4. Task remains in "Waiting for task creation on agent" state indefinitely **Expected behavior** New tasks should be created and registered on the agent, just like existing ones that are still functioning. **Screenshots** <img width="1749" height="374" alt="Image" src="https://github.com/user-attachments/assets/f8b31b3c-6e38-49b5-b485-62bedeca112f" /> **Additional context** - Performed agent repair and agent recovery - No errors visible in web UI - Agent status is "online" with working remote access and check-ins - Two older tasks are still functional and updating status correctly - New tasks do not get created or pushed to the agent Is there a known issue with agent task queues or task sync mechanisms that could cause this? Let me know if you'd like a version with logs attached or to help investigate possible causes.

kerem commented

2026-03-14 07:11:09 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jul 18, 2025):

sounds like this https://docs.tacticalrmm.com/troubleshooting/#celery-queue-stuck

@wh1te909 commented on GitHub (Jul 18, 2025): sounds like this https://docs.tacticalrmm.com/troubleshooting/#celery-queue-stuck

kerem commented

2026-03-14 07:11:14 +03:00

Author

Owner

@Cereal-Killa commented on GitHub (Jul 18, 2025):

sounds like this https://docs.tacticalrmm.com/troubleshooting/#celery-queue-stuck

That fixed it, thank you. What causes this issue, and what measures can be taken to prevent it?

(env) ubuntu@vps-c5:/rmm/api/tacticalrmm$ sudo python manage.py get_celery_queue_length

377995

(env) ubuntu@vps-c5:/rmm/api/tacticalrmm$

@Cereal-Killa commented on GitHub (Jul 18, 2025): > sounds like this https://docs.tacticalrmm.com/troubleshooting/#celery-queue-stuck That fixed it, thank you. What causes this issue, and what measures can be taken to prevent it? > (env) ubuntu@vps-c5:/rmm/api/tacticalrmm$ sudo python manage.py get_celery_queue_length > > 377995 > > (env) ubuntu@vps-c5:/rmm/api/tacticalrmm$

kerem commented

2026-03-14 07:11:20 +03:00

Author

Owner

@second2falcon commented on GitHub (Mar 5, 2026):

sounds like this https://docs.tacticalrmm.com/troubleshooting/#celery-queue-stuck

That fixed it, thank you. What causes this issue, and what measures can be taken to prevent it?

(env) ubuntu@vps-c5:/rmm/api/tacticalrmm$ sudo python manage.py get_celery_queue_length
377995
(env) ubuntu@vps-c5:/rmm/api/tacticalrmm$

@wh1te909 is there a fix implemented in trying to prevent this? I am seeing a similar issue (in my case approximately half the tasks update to "synced with agent" after a few days, but even for online agents, the task was never executed).

Edit: I just checked my queue and it was at 0.

@second2falcon commented on GitHub (Mar 5, 2026): > > sounds like this https://docs.tacticalrmm.com/troubleshooting/#celery-queue-stuck > > That fixed it, thank you. What causes this issue, and what measures can be taken to prevent it? > > > (env) ubuntu@vps-c5:/rmm/api/tacticalrmm$ sudo python manage.py get_celery_queue_length > > 377995 > > (env) ubuntu@vps-c5:/rmm/api/tacticalrmm$ @wh1te909 is there a fix implemented in trying to prevent this? I am seeing a similar issue (in my case approximately half the tasks update to "synced with agent" after a few days, but even for online agents, the task was never executed). Edit: I just checked my queue and it was at 0.

kerem commented

2026-03-14 07:11:25 +03:00

Author

Owner

@wh1te909 commented on GitHub (Mar 5, 2026):

@second2falcon windows tasks are being reworked atm and the concept of "sync status" will not exist anymore (tasks will be scheduled on the server, not agent, using the same scheduler currently present for linux/mac) so this problem will be going away.

@Cereal-Killa cause is race condition, no way to reliably reproduce, so the best way to deal with it is by using https://docs.tacticalrmm.com/tipsntricks/#monitor-your-trmm-instance-via-the-built-in-monitoring-endpoint to alert you if the queue length gets too high so you can take action (can be easily automated as well)

@wh1te909 commented on GitHub (Mar 5, 2026): @second2falcon windows tasks are being reworked atm and the concept of "sync status" will not exist anymore (tasks will be scheduled on the server, not agent, using the same scheduler currently present for linux/mac) so this problem will be going away. @Cereal-Killa cause is race condition, no way to reliably reproduce, so the best way to deal with it is by using https://docs.tacticalrmm.com/tipsntricks/#monitor-your-trmm-instance-via-the-built-in-monitoring-endpoint to alert you if the queue length gets too high so you can take action (can be easily automated as well)