Is there some cool relevance sort of way to detect if a prefetch plug-in is blacklisted? Working my way through patch and my first large deploy last night I had to restart a lot of agents over and over because the prefetch took too long on a few patches…
At 13:11:14 -0600 -
Warning: execute prefetch plug-in command taking more than 2 seconds to complete. It took 3 seconds.
Starting PrefetchPlugIn 'execute prefetch plug-in' "/bin/bash" -c "TMPDIR='{parameter "centosclient_folder"}' '{parameter "centosclient"}' --log_level '{parameter "debug_level"}' --id '{parameter "fixletid"}' --exit_code_file '{parameter "EDR_ExitCode"}' --log_file '{parameter "EDR_Log"}' unarchive_metadata --repos '{parameter "EDR_RepoList"}' --yumcache '{parameter "EDR_YumFolder"}' --yumconfig '{parameter "EDR_Yumconfig"}'" (action 2805521)
At 13:12:14 -0600 -
'execute prefetch plug-in' didn't complete within 60 seconds. Black listing plug-ins matching thename of '' until agent is restarted.
And another question, should I be staggering my deployments over X minutes to reduce this timeout? I’m already planning on maxing out the “_BESClient_ActionManager_PrefetchPlugInTimeoutSeconds” setting.
That might help reduce load on the relay caches and network in general, so it could be a good idea and probably worth doing if it won’t negatively impact anything.
I don’t know what the max is, but I would be careful setting it too high. I probably wouldn’t recommend anything over 1 hour, but I don’t have a ton of experience with it.
Remember a plugin running means the client is doing nothing else at all while this is running. There is no relevance done or anything. We pause all processing to run this plugin and this is why the items get blacklisted if they take too long and why the warning is there.
I’m really struggling to get patch to work consistently on linux endpoints. I have to keep restarting the client, resend to the failed devices… restart the failed clients, then re-send… and on and on. My last set of 180 endpoints, I had to do that cycle 6 times to get all of the patches to deploy completely
I have also used this query before using “properties”, in this case there doesn’t seem to be much:
q: properties whose (it as string as lowercase contains "plugins")
A: banned prefetch plugins of <client>: string
Usually there are a lot more properties that pop up, like these for processor:
q: properties whose (it as string as lowercase contains "processor")
A: main processor: processor
A: processor <integer>: processor
A: vendor name of <processor>: string
A: processors: processor
A: type of <processor>: integer
A: family of <processor>: integer
A: extended family of <processor>: integer
A: model of <processor>: integer
A: extended model of <processor>: integer
A: stepping of <processor>: integer
A: feature mask of <processor>: integer
A: extended feature mask of <processor>: integer
A: speed of <processor>: hertz
A: brand id of <processor>: integer
A: family name of <processor>: string
A: brand string of <processor>: string
A: model name of <processor>: string
A: logical processor count: integer
A: physical processor count: integer
A: total processor core count: integer
I see what you mean. I tried throwing it in a parameter as concatenation " " of banned prefetch plugins of client, but I guess we don’t have any banned plugins because it came back as blank. Maybe you will get a hit on your system.