Each morning, a cron job launches several morning maintenance actions on Linux master server.
Also run are actions to turn CPU settings down if they are up, lock production server endpoints that are not locked etc.
eg: Command is sent to API:
curl -k -X POST --data-binary @/opt/BESServer/scripts/xml/morning_clientcacheclean.xml --user $APIUSER:$APIPASS https://bigfix:52311/api/actions
The command is a sourced fixlet action to launch a BES Support fixlet to clean up client cache.
It's supposed relevant on all endpoints except the BigFix infrastructure in group 585975
Most respond normally, some select clients are not responding to these actions. Even when the endpoint is relevant under the fixlet and will respond when targeted for the action.
Need some help troubleshooting and thought I would check here for helpful links, KB# or other advice before opening a case. Anyone have any good pointers to start?
I'd first check whether those computers are subscribed to the API user operator account.
Normally I'd suspect that those clients are not getting the UDP notifications about new actions getting created - in which case they'd only see the new actions at their 6-hour gather interval; but if these clients are responding to other actions, I think that's less likely.
I totally think it's worthwhile to troubleshoot and determine why these clients are not processing the actions sent by the API user account, but, I also have to wonder, for this very specific action have you considered sending the action once, with settings to reapply daily?
'Run between 01:00 and 02:00' means the action can only run during that one hour of availability; if the client is busy doing something else, or the computer is turned off, the action won't try to 'catch up' by running outside of that designated time.
'Reapply', 'While Relevant, waiting' means that the action doesn't have to be 'Fixed' and then go back to 'Relevant' to repeat (as 'whenever it becomes relevant again' would required).
And waiting 2 hours between reapplications means there's no chance of it running twice in one day, that one-hour block from 0100 to 0200 is too short for the action to run a second time.
Without going down a use case rabbit hole, these jobs were my first use of the API as I we integrated BigFix with Ansible and our monitoring systems to automate pre/post patching actions against endpoints patching at a given time. Actions like unlock/lock, cache cleanup run against the client and group memberships are extracted and endpoints monitors stopped/started.
As these morning jobs triggered via curl/API stop working, so do the other API jobs related to patching. That’s actually how this issue was first noted.
Note: I do use the Execution tab based method you noted to manage other repeating processes, however these legacy jobs have been left in place (not broke/not fixing) and thankfully so. Now I can use them to debug/t-shoot an unexpected issue without touching the patching processes coming out of Ansible that are also affected.
