Skip to content
This repository was archived by the owner on Jan 1, 2021. It is now read-only.

Enable ntpd daemon#1287

Open
tarekch wants to merge 1 commit into
boot2docker:masterfrom
tarekch:ntpd-patch-1
Open

Enable ntpd daemon#1287
tarekch wants to merge 1 commit into
boot2docker:masterfrom
tarekch:ntpd-patch-1

Conversation

@tarekch

@tarekch tarekch commented Nov 30, 2017

Copy link
Copy Markdown

I am using docker-machines as nodes in our Jenkins CI, I noticed that the machines time keeps drifting, After digging into your code, I noticed that the rc.d/ntpd sets the Do Not Demonize flag -n. After a week or so of monitoring, the time sync seems to be working.
Was there a reason for this flag? If not, is this a possible fix?

I am using docker-machines as nodes in our Jenkins CI, I noticed that the machines time keeps drifting, After digging into your code, I noticed that the `rc.d/ntpd` sets the Do Not Demonize flag `-n`. After a week or so of monitoring, the time sync seems to be working.
Was there a reason for this flag? If not, is this a possible fix?
@tianon

tianon commented Dec 7, 2017

Copy link
Copy Markdown
Contributor

We use -n so that we can capture the logs, we end the command with & so that it continues running in the background.

@tarekch

tarekch commented Dec 7, 2017

Copy link
Copy Markdown
Author

Thank you for your valuable input. I did see the & but was surprised that time kept drifting. I should note that i also added /etc/ntpd.conf and add my ntp server ip there instead.

If you believe this is still not related. any ideas why ntpd wasnt working before and now it does? I have read about this issue in many places before without a clear solution.

I would also argue that ntpd should be demonized and the log file is set in the config. I am simply questioning whether u should sacrifice demonizing for a log.

Have a nice day :)

@tianon

tianon commented Dec 8, 2017

Copy link
Copy Markdown
Contributor

We've had a lot of recurring issues with time synchronization in boot2docker. I imagine that your change working better is simply a red-herring -- given enough time, I'd guess that it'd start to exhibit the same issues as the current code, since it functionally isn't any different (except that logs don't go into the same file).

@tarekch

tarekch commented Jan 4, 2018

Copy link
Copy Markdown
Author

Hello,
Just reporting back that I have no issues with ntpd so far. I 100% agree with you that there is no difference between the two commands. However,
What happens if the non-demonized ntpd crashes (for any reason)?
In the case of the demonized ntpd, isnt it the behaviour that it will auto-restart if it crashed? If yes, then demonizing would be the better option here.

@tarekch

tarekch commented Jan 4, 2018

Copy link
Copy Markdown
Author

Also to set the logfile, a logfile /var/lib/boot2docker/log/ntpd.log can be added to an /etc/ntp.conf
the servers can be set in the ntp.conf file. as server entries.
I just can't find a justification for the entire /rc.d/ntpd script; just starting the daemon with three lines in a config file would have sufficed.

@tianon

tianon commented Jan 4, 2018

Copy link
Copy Markdown
Contributor

In the case of the demonized ntpd, isnt it the behaviour that it will auto-restart if it crashed? If yes, then demonizing would be the better option here.

Nope, not at all -- there is literally no difference at all. One way, the daemon starts in the background. The other way, the daemon starts in the background. Both ways, if the daemon dies, the daemon dies.

Does Busybox's ntpd (which is what we're using IIRC) support the logfile directive?

@tarekch

tarekch commented Jan 5, 2018

Copy link
Copy Markdown
Author

I gave it a try and unfortunately no :(
ntpd: skipping /etc/ntp.conf:2: unimplemented command 'logfile'

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants