$CHECKSOURCE$ Standard Macro Not Populated

[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?

[kg2857]

I don't see it in the macro list.
https://assets.nagios.com/downloads/nag ... olist.html

[ykara84]

I don't see it in the macro list.
https://assets.nagios.com/downloads/nag ... olist.html

Hi, it's listed on the Core v4 page:

https://assets.nagios.com/downloads/nag ... olist.html

[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

[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.

[ykara84]

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

[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

[DoubleDoubleA]

https://github.com/NagiosEnterprises/na ... ssues/1044

[ykara84]

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.