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

Force sync system clock not working #90

Open
ko-be opened this issue Jan 9, 2015 · 10 comments
Open

Force sync system clock not working #90

ko-be opened this issue Jan 9, 2015 · 10 comments

Comments

@ko-be
Copy link
Contributor

ko-be commented Jan 9, 2015

On a large number of our CentOS 6 & 7 machines, the 'ntpd -q' command (in https://github.com/gmiranda23/ntp/blob/master/recipes/default.rb#L96) is not running properly as the ntpd service does not appear to be stopping before running the command. To work around it, we have been setting ['ntp']['sync_clock'] to false.

Instead of an execute block that notifies the ntpd service (https://github.com/gmiranda23/ntp/blob/master/recipes/default.rb#L92), if it's rewritten to be a service block that stops ntpd, then runs ntpd -q, then another service block that starts ntpd, it appears to work properly.

@gmiranda23
Copy link

@ko-be the recipe runs cleanly. can you elaborate on how you determine it is not running properly?

also, if you have this working reliably it'd help to see your code. please open a PR if you have a mockup available.

@ko-be
Copy link
Contributor Author

ko-be commented May 15, 2015

@gmiranda23 we are actually still running into this issue, and very sporadically. Once we figure out the exact cause and figure out a fix, I'd be happy to open a PR to fix the issue. For now, we've had to disable this to get ntp to converge 100% of the time. For reference, we are running into this on CentOS 7 more recently.

@anuragpaliwal80
Copy link

I am also facing the similar problem on CIS CentOS 7 and output is

amazon-ebs: * service[ntp] action stop (up to date)
    amazon-ebs: * execute[Force sync system clock with ntp server] action run
    amazon-ebs: Error executing action `run` on resource 'execute[Force sync system clock with ntp server]'
    amazon-ebs: Mixlib::ShellOut::ShellCommandFailed
    amazon-ebs: ------------------------------------
    amazon-ebs: Expected process to exit with [0], but received '1'
    amazon-ebs: ---- Begin output of ntpd -q ----
    amazon-ebs: STDOUT:
    amazon-ebs: STDERR:
    amazon-ebs: ---- End output of ntpd -q ----
    amazon-ebs: Ran ntpd -q returned 1
    amazon-ebs: Resource Declaration:
    amazon-ebs: ---------------------
    amazon-ebs: # In /tmp/packer-chef-solo/cookbooks-0/ntp/recipes/default.rb
    amazon-ebs:
    amazon-ebs: 96:   execute 'Force sync system clock with ntp server' do
    amazon-ebs: 97:     command 'ntpd -q'
    amazon-ebs: 98:   end
    amazon-ebs: 99:   service 'ntp' do
    amazon-ebs:
    amazon-ebs: Compiled Resource:
    amazon-ebs: ------------------
    amazon-ebs: # Declared in /tmp/packer-chef-solo/cookbooks-0/ntp/recipes/default.rb:96:in `from_file'
    amazon-ebs:
    amazon-ebs: execute("Force sync system clock with ntp server") do
    amazon-ebs: action [:run]
    amazon-ebs: retries 0
    amazon-ebs: retry_delay 2
    amazon-ebs: default_guard_interpreter :execute
    amazon-ebs: command "ntpd -q"
    amazon-ebs: backup 5
    amazon-ebs: returns 0
    amazon-ebs: declared_type :execute
    amazon-ebs: cookbook_name :ntp
    amazon-ebs: recipe_name "default"
    amazon-ebs: end

How should we solve this?
Thanks,
Anurag

@pietervogelaar
Copy link

I have the same issue on CentOS 7. It fails randomly about 4 out of 10 times.

@sdarwin
Copy link

sdarwin commented Jan 25, 2016

Greetings,
I submitted a pull request that did fix this issue for us. #125 Please try it out and let me know. To manually apply the change, just move the ntp service to the top of the file in the default recipe, and set it's action to nothing. Then add a placeholder at the bottom of the file, that enables and starts the service. Refer to the commit in the pull request.

@Knappek
Copy link

Knappek commented Apr 27, 2016

I run into the same issue in centos 7

================================================================================ Error executing actionrun` on resource 'execute[Force sync system clock with ntp server]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of ntpd -q -u ntp ----
STDOUT: 
STDERR: 
---- End output of ntpd -q -u ntp ----
Ran ntpd -q -u ntp returned 1

Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/ntp/recipes/default.rb

 99:   execute 'Force sync system clock with ntp server' do
100:     command "ntpd -q -u #{node['ntp']['var_owner']}"
101:     action :run
102:     notifies :start, "service[#{node['ntp']['service']}]"
103:   end
104: end

`

I figured out, that this occurs after a reboot of the node. If I start ntp daemon manually with sudo service ntpd start and run chef-client again, it works.

@sdarwin
Copy link

sdarwin commented May 3, 2016

Knappek, to enable a service on boot in centos 7: systemctl enable servicename.service
or, in a chef recipe, "action :enable"
it shouldn't be necessary to start the standard services manually on reboot.

@Knappek
Copy link

Knappek commented May 3, 2016

Yes, it needs to be implemented in this cookbook. The cookbook fails after a reboot at this LWRP: https://github.com/gmiranda23/ntp/blob/master/recipes/default.rb#L99

@sdarwin
Copy link

sdarwin commented May 3, 2016

Knappek, I submitted a pull request that fixed the bug, at least for us. It is mentioned earlier in this thread, maybe you could try it out.

@Knappek
Copy link

Knappek commented May 3, 2016

Thank you, I will try that out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants