[GH-ISSUE #1573] Feature Request: Do not "fail" checks/tasks for scripts that "Run As User" and the user is not logged in #2928

New issue

Closed

opened 2026-03-14 05:59:21 +03:00 by kerem · 1 comment

kerem commented

2026-03-14 05:59:21 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Jul 23, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1573

Originally assigned to: @wh1te909 on GitHub.

Is your feature request related to a problem? Please describe.
Create a script that is to be run in the user context and has the Run As User checked. Then create a check or task that runs the script. If the user is not logged in, the check/task will always fail and generate an alert. For the Task, the alert severity is the severity chosen in the task. For checks, the alert severity can be changed by entering the return code 66 (see below) in the appropriate field to make the alert informational/warning/error.

The problem is you can't disable the alert. It always fires because the script itself is never run. When the agent goes to run the script, if the user is not logged in, the script fails. There is no way to control this "failure" and disable the alert.

Describe the solution you'd like
I don't want to be notified if the user is not logged in for scripts that require a user to be logged in. Maybe have a checkbox to "Treat 'no user session found' as error" or perhaps "Ignore 'no user session' errors."

Describe alternatives you've considered
One very tricky alternative is to disable alerts for the policy, then check the SMS/email/dashboard alerts for all checks/tasks except the ones that are run as the user.

Another alternative is to create a policy that has only user scripts, and configure the alerting appropriately for that policy. This will consume one of the global/client/site/agent policies that can be applied.

Additional context
Here is the text that is shown in the script output generating the alert.

Last Run: Jul-23-2023 10:55
Run Time: 0.0383808 seconds
Return Code: 66

Standard Error

no active session found

Originally created by @NiceGuyIT on GitHub (Jul 23, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1573 Originally assigned to: @wh1te909 on GitHub. **Is your feature request related to a problem? Please describe.** Create a script that is to be run in the user context and has the _Run As User_ checked. Then create a check or task that runs the script. If the user is not logged in, the check/task will always fail and generate an alert. For the Task, the alert severity is the severity chosen in the task. For checks, the alert severity can be changed by entering the return code `66` (see below) in the appropriate field to make the alert informational/warning/error. The problem is you can't disable the alert. It always fires because the script itself is never run. When the agent goes to run the script, if the user is not logged in, the script fails. There is no way to control this "failure" and disable the alert. **Describe the solution you'd like** I don't want to be notified if the user is not logged in for scripts that require a user to be logged in. Maybe have a checkbox to "Treat 'no user session found' as error" or perhaps "Ignore 'no user session' errors." **Describe alternatives you've considered** One very tricky alternative is to disable alerts for the policy, then check the SMS/email/dashboard alerts for all checks/tasks **except** the ones that are run as the user. Another alternative is to create a policy that has **only** user scripts, and configure the alerting appropriately for that policy. This will consume one of the global/client/site/agent policies that can be applied. **Additional context** Here is the text that is shown in the script output generating the alert. ```text Last Run: Jul-23-2023 10:55 Run Time: 0.0383808 seconds Return Code: 66 Standard Error no active session found ```

kerem

2026-03-14 05:59:21 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-14 05:59:37 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jul 30, 2023):

I have changed the behavior to just continue running the script and ignore the error, will be in next release (will require agent update)

@wh1te909 commented on GitHub (Jul 30, 2023): I have changed the behavior to just continue running the script and ignore the error, will be in next release (will require agent update)