New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Why do some OVZ providers not like ntpd?
I currently have 3 open tickets to OVZ providers trying to get the time synced correctly. Each ticket has been open for days. Is there some reason that these providers don't like to install ntpd?
Servers with a thousand times more capacity than NASA had when they put a man on the moon -- and they can keep correct time. It's frustrating 
This discussion has been closed.
Comments
That's what first comes to mind
But in these cases the providers are excellent. The service is excellent. It's just the damned clock....
IMO OpenVZ providers are so lazy to correct issues with stock installations or do not have enough experience on linux.I also had issues with six(6) different openvz providers, not any of them were able to enable xtstring of iptables on their nodes.
http://lowendtalk.com/discussion/10247/enabling-xt-string-module-on-openvz-containers
One exception is buyvm.They have the capability to correct issues on linux.
yum install ntp && chkconfig ntpd on && ntpdate pool.ntp.org && /etc/init.d/ntpd start
It is really that simple. Really.
I don't think it's about the technical competence of the provider. If I were to name the three (which I'm not) you'd all say, "yeah they're good"
Is it maybe because of that ntpd bug last year, that some providers are afraid of it?
It's the only reason I can think of.....
Maybe very well possible that they don't have any script to auto setup nodes and might have forgotten while setting it up manually?
Maybe. But with tickets open, I still can get any ntp joy.
Every network daemon running on the node is a potential security risk. There is always a tradeoff between features and security.
I can appreciate that. But I don't consider an accurate clock to be a "feature"
Certainly there must be some solution, rather than simply letting the clock drift.
I have a better question: why do you care? How does an incorrect system clock affect you?
How is that a better question?
Unless you have an OCD for having the exact on-second time on your VPS, there's no big fuss about it being off.
In the cases where I have issues now, the clock are off by 70 seconds, 97 seconds and 138 seconds. And still drifting by 1-2 secs/day. Some of my services encounter errors when the clock is too far out off sync.
I'd be perfectly happy with an accuracy of +/- 10 seconds
I take it you've never used time-sensitive, or relative, applications.
Received quite a few of these tickets in the past. Don't see a problem with doing it. Understands the need for it. Maybe try to push a bit harder if not hm.
Hey, at least your VPS isn't off by 17 hours
My Aim2Game got rebooted randomly yesterday and now everything is frelled.
Had a bizzare problem on BuyVM with time racing forward with the speed of like a week in 10 minutes, the reason was some incompatibility involving 64-bit vs 32-bit. My guest was 64-bit, and their proposed "solution" was to reinstall everything and change to 32-bit. Which would only be half as ridiculous if it wasn't them who told me to install a 64-bit system couple of months before that in the first place (despite 128 MB of RAM), to fix ip6tables not working on a 32-bit guest... So no, they did not strike me as exceptionally capable in the "correcting issues" aspect.
The best solution is to avoid OpenVZ completely. Seriously, save yourself the time and nerve cells spent waiting on tickets for these stupid issues.
BlueVM doesn't use ntpd because we once had a VERY strange interaction between it and HyperVM. Damn HyperVM.
Maybe you could run ntpdate every few days? Or the drift could be really big...
With ntpdate sadly you can get hit by this:
that's a message from Tor, but other software also may go crazy if time just jumps back and forth under them. ntpd at least tries to adjust it gradually. For that reason I am moving away from ntpdate currently, even though I liked not having to run a whole extra daemon just to set time.
@rm_ you can try running ntpdate more often (like every 5 minutes). Hopefully the jump then would be less than a second and the software wouldn't notice it. Not sure if this would help though.
I was running it every 6 hours. The synchronization server (and just one) is chosen randomly, so maybe I got some "bad" one. AFAIK ntpd always checks with at least 3 servers.
Hum @rm_, I also had that same problem, and exactly 123 seconds... Was either the same provider, a big coincidence or some other error that makes the clock jump 123 seconds. In my case the message was repeated many times.
rsync, distributed DB/FS, certificate revocation, dnssec validation etc.
inaccurate clock loses consistency and security.
It was on my dedi, so no, not same node. Perhaps it's just a bug in Tor instead.
Can't think of a reason not to... providing accurate time within a few seconds to clients should be mandatory, especially with how easy it is to set up and then forget about it.
Speaking of forget, that's usually where we fail... I finally added it to my "new node" checklist, so it shouldn't take a couple of weeks for me to notice that the time is off on the node.
It's literally like 2-3 commands and done. I don't see why anyone wouldn't run ntp.
This issue isnt about installing its about openvz not allowing it unless allowed.
All Openvz Providers need to do is the following command
CTID replaced by Container ID
vzctl set CTID --capability sys_time:on --save
Restart vps an then ntpd update sync will work. Otherwise by default users get Operation not permitted error when syncing.
However as all VPS share same clock, Wouldn't just running sync on host node only not containers be better.
Would that allow every VPS to set the global time for the node? Or does it just impact the VPS?
Its per VPS, As mainly node should run time sync only an all vps's will use that sync'd time.
Otherwise several containers would all be syncing the same clock which is just pointless. So long as host node is syncing all times should be ok. If provider doesnt want to run ntp on host node, They can allow specific vps's to do it using command above.
Yes.
No.