Page 1 of 1
$CHECKSOURCE$ Standard Macro Not Populated
Posted: Mon Nov 24, 2025 7:18 am
by ykara84
We are using XI 2024 R2.1 with a python script to send notifications to ServiceNow as incidents by passing the service/host alert related
Standard Macros to the py script.
The macros work perfectly except the
$CHECKSOURCE$ one which is supposed to contain the
Source worker for a host or service check. however it only seems to contain a
$ character, not the worker name even though we have service and host checks running from workers.
Any one seen this before or know how to fix/troubleshoot it?
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Mon Nov 24, 2025 8:02 pm
by kg2857
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Tue Nov 25, 2025 4:10 am
by ykara84
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Tue Nov 25, 2025 10:26 am
by DoubleDoubleA
It's definitely a macro in Core 4. The worker it references can be one of the local Core worker processes, or it could be a Gearman worker.
Ideally all macros should just work, though I am not how this one works under the hood. The docs don't give us much there, and the source code, from at least a short study, doesn't reveal tons either. Core's passing pointers around, and I'm not sure where it starts doing that in an effort to make sure it's probably doing what we think it should be doing.
As one looks at the footnotes on that page, it's clear that some macros work differently than others, and while there's no footnote for this one it may operate differently than we might expect.
Presumably your python code works the same for this macro as it does for the other macros that are working as expected, but it might not hurt to go back through that code and make sure.
I'll admit I'm curious as to your use case, and how you will use the info the macro says it provides.
Aaron
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Tue Nov 25, 2025 6:12 pm
by kg2857
I'd guess the macro isn't actually defined. The OP might test by using an undefined macro and see if it behaves the same way.
Only seeing the $ char sounds a lot like it's seeing the first part as an undefined variable, and the trailing $ as a character.
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Wed Nov 26, 2025 6:42 am
by ykara84
DoubleDoubleA wrote: ↑Tue Nov 25, 2025 10:26 am
It's definitely a macro in Core 4. The worker it references can be one of the local Core worker processes, or it could be a Gearman worker.
Ideally all macros should just work, though I am not how this one works under the hood. The docs don't give us much there, and the source code, from at least a short study, doesn't reveal tons either. Core's passing pointers around, and I'm not sure where it starts doing that in an effort to make sure it's probably doing what we think it should be doing.
As one looks at the footnotes on that page, it's clear that some macros work differently than others, and while there's no footnote for this one it may operate differently than we might expect.
Presumably your python code works the same for this macro as it does for the other macros that are working as expected, but it might not hurt to go back through that code and make sure.
I'll admit I'm curious as to your use case, and how you will use the info the macro says it provides.
Aaron
We use a Nagios I command like this:
Code: Select all
python3.12 $USER1$/Snow-Integration/incident-creator.py "$HOSTNAME$" "$HOSTSTATE$" "$HOSTSTATETYPE$" "$LASTHOSTUP$" "$LASTHOSTSTATECHANGE$" "$HOSTOUTPUT$" "$HOSTEVENTID$" "$HOSTPROBLEMID$" "$HOSTGROUPNAMES$" "$CHECKSOURCE$" "$HOSTNOTIFICATIONID$" --hosts
Which is triggered by a Nagios XI notification. It ends up creating an incident that looks like below (e.g. Host Down)
Screenshot 2025-11-27 094708.png
The ideas was to use the worker set in $CHECKSOURCE$ to help engineers debug/resolve the check result just in case the check was returning different results from different workers. worker_source is meant to contain the value of $CHECKSOURCE$. You can see in the screenshot
host_output field actually references the worker
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Wed Nov 26, 2025 12:22 pm
by DoubleDoubleA
Hi @ykara84,
@kg2857 is correct (thanks kg2857!) that the macro is undefined in the code, although interestingly we seem to keep track of the information, and also interestingly we somehow decided to put it in the documentation.
It is interesting that $HOSTOUTPUT$ is showing the worker, but as I read the documentation there it seems like it must be that your plugin in that case is adding that info to its return.
I don't find any reference to $CHECKSOURCE$ in the changelog, for either adding or removing, so if I had to guess it was perhaps never implemented, but I can't say for sure.
Could we implement it? Possibly, though in the short term the most likely fix is that we remove it from the doc.
If your plugin is returning worker info, perhaps you could parse it out of there in the short term to make it available as its own item in the SNOW workflow.
Thoughts?
Aaron
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Wed Nov 26, 2025 1:55 pm
by DoubleDoubleA
Re: $CHECKSOURCE$ Standard Macro Not Populated
Posted: Thu Nov 27, 2025 4:43 am
by ykara84
DoubleDoubleA wrote: ↑Wed Nov 26, 2025 12:22 pm
Hi @ykara84,
@kg2857 is correct (thanks kg2857!) that the macro is undefined in the code, although interestingly we seem to keep track of the information, and also interestingly we somehow decided to put it in the documentation.
It is interesting that $HOSTOUTPUT$ is showing the worker, but as I read the documentation there it seems like it must be that your plugin in that case is adding that info to its return.
I don't find any reference to $CHECKSOURCE$ in the changelog, for either adding or removing, so if I had to guess it was perhaps never implemented, but I can't say for sure.
Could we implement it? Possibly, though in the short term the most likely fix is that we remove it from the doc.
If your plugin is returning worker info, perhaps you could parse it out of there in the short term to make it available as its own item in the SNOW workflow.
Thoughts?
Aaron
Thanks Aaron. It not a major issues for us, to be honest it was only a 'nice to have' detail in the incident but I wanted to report it as it looked like a bug to me. Hopefully it will be fixed off the back of your GitHub issue.