New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixlib::Shellout can return nil exitstatus in low-RAM situations #4857
Comments
status.exitstatus being nil isn't a bug in the yum provider, that would be a bug in mixlib-shellout (or possibly the underlying calls that ruby makes -- probably to waitpid? -- to gather the exitstatus) makes me wonder if its failing to fork and exec because you're running out of RAM+swap or something like that. |
Thank you @lamont-granquist Agree it is mixlib-shell out not correctly returning rather than Yum provider but as the issue manifests itself there I thought I'd log the bug as that resource. Thanks for the pointer, I'll up the specs of the VM and keep an eye on the system resources during converge. |
@lamont-granquist We bumped the specs of the VM and it converges without issue. Not sure what you want to do with this? |
ideally it'd be nice to track down the codepath its going through in mixlib-shellout and have it raise an exception rather than returning nil. since it can't ever be fixed, though, and bumping up the system limits is the 'fix' its probably very low priority compared to other bugs. |
ultimate root cause was probably caused by yum-dump.py in the yum_package provider consuming too much RAM which will be gone in #6540 fixing the mixlib-shellout error message is so low-priority, that i think we're never going to get to it, so just closing this |
Description
We have a large cookbook that fails when running a package 'cronie' resource.
However this is NOT an issue installing the cronie package, if the package 'cronie' resource is removed from the cookbook we get the same error later on installing another package. This appears to be an issue with the YUM package provider.
Chef Version
12.8.1
Platform Version
CentOS 6.7
Replication Case
Unfortunately at present I am unable to re-create the issue in a small cookbook, the problem only appears when running our Environment cookbook (a cookbook containing a collection of application cookbooks).
The failure message is
The reason for the message is due to the code in yum_command method of the Chef::Provider::Package::Yum. What we are finding is that the status.exitstatus value is nil
The code runs
The error is caused by comparing status.exitstatus > 0, hence nil method error.
Client Output
As already mentioned although we saw this error installing 'cronie' but it is a YUM package issue, we've had other similar messages installing different packages (below)
We do tend to write code like this
So I've added a delay between the installation of each package to eliminate that possibility, it does seem to work better so I'm thinking it could be the number of command calls to yum/rpm combined with cookbooks removing and re-installing packages to quickly?
Stacktrace
Please include the stacktrace.out output or link to a gist of it, if there is one.
Misc
Some YUM provider package resources do not even get as far as running yum_command because they do not get past the checks in the package run_action (see below)
Of the ones that do pass the check, the majority come back with the status object correctly set.
NOTE: CHEF CLIENT BUGS ONLY
This issue tracker is for the code contained within this repo --
chef-client
, baseknife
functionality (notplugins),
chef-apply
,chef-solo
,chef-client -z
, etc.The text was updated successfully, but these errors were encountered: