Hello,
I choose a server from the list of computers.
I get a list of 400 fixlets.
After I choose 100 of them and took the default actions, I saw they all failed.
Looking at the log on the server, I see that they are all “Not Relevant”.
So why am I seeing them in the list of relevant fixlets for that server?
Thanks
That can be difficult to determine without more detail, but I’d first check that the ‘Last Report Time’ of the computer appears current in the console, to make sure you aren’t seeing older reported relevance.
Next I’d start with just one Fixlet instead of hundreds. If it still gives the unexpected result, ask about it here.
Also be sure of what you’re seeing on the BESClient log. An Action may display a ‘Not Relevant’ message in the log after it actually executes - in that context ‘Not Relevant’ means that it only.executes once and is not eligible for Retry/Reapply logic. Check whether the action actually ran first before giving the ‘Not Relevant’ message after execution.
Hi Jason.
Thanks for the replay.
I just did another test. Choose on server and run one of the fixlets.
After it failed with erro “not relevant” in the log on the server, I refreshed the list and I can still see the same fixlet in the relevant list for that server 
You can see the fixlet in the list in the pictue and the failed. after that I got the same list with the same fixlet still available…
after getting the “failed”, I just the same thing as in the message again.
I also have the log but can’t upload it yet (I am a new user here…).
But it looks like every thing is successful and at the end it say “|Not Relevant”.
Thanks.
I had the following situation - Action started with the “Pending Downloads” status and the status would not change and then it expired - the status changed to “Not Relevant”
Is this the behavior you are experiencing?
Hi or,
No. The status seems like it turn to “Failed”.
I see the “not relevant” only in the log on the server.
The last log entry on the endpoint showing ‘Not Relevant’ is likely a normal condition. That just indicates the action has finished processing (regardless of whether or not it was successful). You’d need to look into what comes before those messages, or the status in the Console, to see whether the thing succeeded or failed.
For example, here is a snippet of my logfile showing from start to finish an Action that has one line of ActionScript
At 11:27:23 -0600 - mailboxsite (http://BES-Dev-Root:52311/cgi-bin/bfgather.exe/mailboxsite539193122)
Relevant - Custom Action (fixlet:148521)
At 11:27:23 -0600 -
ActionLogMessage: (action:148521) Action signature verified for Execution
ActionLogMessage: (action:148521) starting action
At 11:27:23 -0600 - actionsite (http://BES-Dev-Root:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded parameter "SomeParam"="SomeValue" (action:148521)
At 11:27:23 -0600 -
ActionLogMessage: (action:148521) ending action
At 11:27:23 -0600 - mailboxsite (http://BES-Dev-Root:52311/cgi-bin/bfgather.exe/mailboxsite539193122)
Not Relevant - Custom Action (fixlet:148521)
The first message shows the Action becoming Relevant. Note that ‘fixlet:148521’ refers to an action id 148521, not the ID of a source fixlet (if there was one).
The next message shows that the Action’s signature has been verified for Execution. (If the action had Downloads, those would have processed first and then this ‘verified for Execution’ would be displayed after downloads had completed).
Right after that the ‘starting action’ message shows where it actually beins to execute.
My action only does one thing - setting a parameter “SomeParam”, just to make something appear in the log file.
Next is the message for ‘ending action’, and finally a ‘Not Relevant’ message.
Don’t focust on the ‘Not Relevant’ message, that comes at the end of the action, look for the messages that may have come before. Search your log for action:123 for whatever action ID you are trying to find.
@royzo I’ve seen that you are talking about RHEL Patching - Please look into the Troubleshootung section - https://help.hcltechsw.com/bigfix/10.0/patch/Patch/Patch_RH/c_troubleshooting.html - The action reported back as a failed download
Look also into the EDRDeployment.log file
Hi Jason,
Maybe I just don’t understand how that thing is working.
In your case, after running your custom fixlet that update parameter, Does it still stay on the “Relevant Fixlets and Tasks” or does it remove it from the list?
Because, In my case, I see the fixlet:
"RHSA-2023:0383 - Libxpm Security Update - Red Hat Enterprise Linux 9 (x86_64) (fixlet:12614)"
In the list, and after running it and getting “Not relevant” in the log, And it doesn’t matter way it is not relevant, I except it to not show up again in the “Relevant Fixlets and Tasks”. Am I wrong? Doesn’t it suppose to disappear?
Maybe I got something wrong with my understanding of how it work?
Your expectation is correct; once a fixlet is successfully executed, it should no longer be relevant, and as @JasonWalker pointed out, the “Not Relevant” statement appears after the execution of an action within a log file, regardless of whether it fail or pass.
You should look into your action status, Try these steps:
Go to your specific action and see what the status is. If it failed, you would see something like this:
When you right-click on your device’s name or failed status, you will see the option “View Action info” (see below), which will tell you if there was a command execution failure.
Since this is Linux patch, you will dont find much info about it in BESClient’s normal logging, you need to look into EDR logs which is also suggested by @orbiton.
If the Action status is Fixed but the machine still shows applicable to it, try the following:
i. Try verifying its applicability locally on that device; there could be something that is still not matching. You can open local QNA using the command `/opt/BESClient/bin/qna` and test each relevance statement; if all show "False," it means the fixlet is not relevant and the client is not syncing properly.
ii. Try sending a force refresh by right-clicking on that device and selecting "send force refresh".
iii. Remove the BESClient __BESData folder; resetting BESClient's gather state solves the problem.
If you are still unsure, I recommend speaking with your BigFix Admin or opening a case with HCL for further understanding and troubleshooting.