I’m having some inconsistencies when trying to have clients execute tasks at specific times, today I scheduled a task to execute at 07:00 UTC across 228 RHEL servers across multiple timezones and virtualisation platforms.
149 servers executed within 1min (between 07:00:00) and 07:00:59)
33 servers executed within 5min of the scheduled time.
43 servers executed it within the first hour (before 08:00UTC)
3 servers very late at:
08:37:32
09:30:05
10:05:23
The task is configured as this and was submitted atleast 18 hours before the task time.
Execution
This action starts 12/11/2024 7:00:00 AM UTC and ends 12/12/2024 12:00:00 PM UTC.
It will run at any time of day, on any day of the week.
If the action becomes relevant after it has successfully executed, the action will not be reapplied.
If the action fails, it will not be retried.
I am only using the “starts on” contraint, not “run between”.
Is this expected behavior? Am I able to ensure that the servers execute the task closer to the scheduled time?
Well, the client continually evaluates its content: at each evaluation cycle, if the action is relevant and the start time was reached, the execution starts; otherwise, another cycle begins. Probably, on the “delayed” machines you have long evaluation cycles.
You can check it with (average duration of it, maximum duration of it) of evaluationcycle of client : https://developer.bigfix.com/relevance/reference/evaluation-cycle.html
You can reduce the evaluation cycle by reducing the content/sites client is subscribed to and/or by increasing the client cpu usage: Configuring Client CPU Utilization
Also consider some of those clients may not be receiving UDP messages informing them of the new action, due to network blocks or the RH Firewall. Check Tip: Troubleshooting Client Reponsiveness for more tips on determining if that is the case, and workarounds such as opening the traffic, enabling Command Polling,or Persistent Connections.
I was also going to ask about the possibility of the UDP packet not being received by the client and relying on command polling to check in periodically.
It’s possible you didn’t look at it beforehand but i’d be curious if those clients that started late were sitting at waiting or not reported before the scheduled start date. It’s possible that the clients aren’t receiving the UDP packet that says that they have jobs to process and processed the job when it checked in for normal check-in or when the command poll time period hit.
What is most interesting to me is that you submitted this Action 18hrs in advance. That is more than sufficient time for every endpoint to become of aware of something to do at a specific time.
After submitting, did every client have an action status of “Waiting”? If so, that means the BES Client on every endpoint knew about the job and should start exactly on time (within seconds). If not, then there is some type of major client communication issue. If they did have a waiting status, then I am wondering if the endpoint was under load and opted to not start the task.