Skip to content
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

chef-client runs and exits successfully but the process hangs around afterwards #45

Closed
jrieck1991 opened this issue Jun 29, 2017 · 5 comments
Labels
Type: Bug Does not work as expected.

Comments

@jrieck1991
Copy link

Cookbook version

chef_client_updater 1.0.2

Chef-client version

chef-client 12.17.44

Platform Details

CentOS 6.9

Scenario:

chef-client runs and exits successfully but the process hangs around afterwards, this doesn't stop chef-client from running again but it does trigger alerts on our side for the lingering process.

Steps to Reproduce:

It only happens on a small section of our nodes, I have no idea how to reproduce. I have an inkling that due to upgrading chef-client the old pid gets left and doesn't get overwritten with the new version chef-client pid.

Expected Result:

chef-client doesn't show up with ps -ef

Actual Result:

chef-client is show in ps -ef

@lamont-granquist
Copy link
Contributor

does switching the post install action to 'kill' fix it?

@tas50 i'm kind of wondering if that default needs to be flipped.

@tas50
Copy link
Contributor

tas50 commented Jun 29, 2017

I just came here to mention that we should probably change it to kill. We certainly need some more detailed documentation about the importance of the post install action and making sure you have the right setting. It seems to be causing a lot of confusion. I wonder if we could make it smarter about just doing the right thing.

@lamont-granquist
Copy link
Contributor

so if we want to do that we should probably do that before 3.0.0 drops so we don't have to do a 4.0.0 a few days later

@iennae iennae added the Type: Bug Does not work as expected. label Jun 30, 2017
@mhedgpeth
Copy link

Now that it's set to :kill by default this works. I just tested it.

@tas50 tas50 closed this as completed Jul 14, 2017
@tas50
Copy link
Contributor

tas50 commented Jul 14, 2017

Good to hear @mhedgpeth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Does not work as expected.
Projects
None yet
Development

No branches or pull requests

5 participants