Linux patch plugin exit 201

We are getting ready to start patching CentOS and I’m seeing this occasional hiccup that is quite annoying. Sometimes a patch in the baseline will fail with exit code 201 (with the same error code on the patches after that). In the EDR_DeploymentResults.txt I see:

20564    : 2018-03-12 11:22:22 : INFO     : Unzip .sqlite.bz2 in metadata: CentOSUpdates
20564    : 2018-03-12 11:22:41 : INFO     : Unzip .sqlite.bz2 in metadata: CentOSOS
20564    : 2018-03-12 11:22:43 : INFO     : Unzip .sqlite.bz2 in metadata: CentOSFastrack
20564    : 2018-03-12 11:22:43 : INFO     : Unzip .sqlite.bz2 in metadata: CentOSExtras
20567    : 2018-03-12 11:22:43 : INFO     : 04 dependency resolution and request packages
20567    : 2018-03-12 11:22:43 : INFO     : Download Plugin mode.
20567    : 2018-03-12 11:22:43 : INFO     : Run cmd: env: {} cmd: yum --verbose --cacheonly -c /var/opt/BESClient/EDRDeployData//EDR_Yumconfig_2790805 --bf_dependency_resolution install --assumeyes coreutils-8.4-46.el6.x86_64
20567    : 2018-03-12 11:22:44 : ERROR    : Dependency resolution failed.
20567    : 2018-03-12 11:22:44 : ERROR    : No packages are available.
20567    : 2018-03-12 11:22:44 : ERROR    : Exit Code: 201
Loading "yum-centosplugin" plugin
Config time: 0.041
Yum Version: 3.2.29
rpmdb time: 0.000
Setting up Install Process
Setting up Package Sacks
pkgsack time: 0.039
Building updates object
up:Obs Init time: 0.051
up:simple updates time: 0.004
up:obs time: 0.001
up:condense time: 0.000
updates time: 0.117
Package coreutils-8.4-46.el6.x86_64 already installed and latest version
Nothing to do
	

20571    : 2018-03-12 11:22:54 : ERROR    : yum command not continue, last command exit code is not 0

…if I try to re-run, same result. But if I restart the client, all is well. That patch works and the subsequent patches in the baseline start working as well.

I guess my question is, has anyone else seen this be an issue? Have you found a way around it? Do you just restart the client before a patch cycle just to prevent the error?

In the end, this was a bug in the CentOS (6 & 7) content. The ended up updating all of the CentOS patch content to include some default timeouts.

That said, things are better… not totally fixed. Now I only had 5 out of 165 fail due to the timeout issue. I still had to restart the agent to get things back in a state where I could retry the patch baseline.