Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Setting system time in OpenVZ container?
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.

Setting system time in OpenVZ container?

swsnyderswsnyder Member
edited August 2012 in General

I've got several OpenVZ VPSs with a single vendor. The system time is grossly inaccurate in 2 of the VPSs. This being OpenVZ, the system time/date is inherited from the host. The vendor seems unable to set the host time correctly.

(No, I am not referring to the time zone. I mean the base time to which the time zone is applied as an offset.)

My vendor is not unwilling to change the time, just unable to do it. I have no reason to think he is lying to me when he says that he has corrected it x times already. He's not obstinate, just incompetent.

Accurate system time is critical for DNSSEC and desirable for logging and other administrative tasks. Having a system time that is several hours out of sync with the rest of the world just won't do.

Do I have any recourse at all in setting the system time in an OpenVZ container that doesn't involve reconfiguring the host system?

Thanks.

Comments

  • TheHackBoxTheHackBox Member
    edited August 2012

    Tell your provider that ntpdate is super super easy to do. Only a few seconds to sync the time really. And no you cannot change the time in OVZ. If you need to change the time either get your provider to so or move to KVM/Xen.

    Thanked by 1dragonballz2k
  • Nick_ANick_A Member, Top Host, Host Rep
    edited August 2012

    yum install rdate -y
    rdate -s rdate.cpanel.net

    Done.

    EDIT: I am commenting from the host's perspective. It is quick and easy.

    Thanked by 1ExonHost
  • lbftlbft Member
    edited August 2012

    @swsnyder said: Do I have any recourse at all in setting the system time in an OpenVZ container that doesn't involve reconfiguring the host system?

    No. You can change the time zone, but not the time.

    The host needs to install ntpd (assuming it's CentOS, a simple yum install ntp should get it up and running, pre-configured with pool.ntp.org time servers IIRC.) That will prevent more clock drift in the future as well.

    Thanked by 1Root
  • Down with containers. Up with real VPS!

  • RootRoot Member
    edited August 2012

    @lbft said: The host needs to install ntpd (assuming it's CentOS, a simple yum install ntp should get it up and running, pre-configured with pool.ntp.org time servers IIRC.) That will prevent more clock drift in the future as well.

    I second the motion for running NTPd; this should be a requirement when selecting a host using any environment where a virtual clock (that you can set) is not available like OpenVZ or Virtuozzo.

    To the best of my knowledge, ntpd is off by default after its RPM installation (in CentOS 6); because of this, I usually perform something like the following steps/commands for initial RPM installation with a one-time sync before starting the daemon:

    yum -y install ntp
    ntpdate -v clock.isc.org
    chkconfig ntpd on
    service ntpd start
    
    Thanked by 1lbft
  • my personal setup script includes this if it's not an openvz vps:

    yum -y install ntp
    ntpdate -u x2la01.hostigation.com
    echo "23 */4 * * * root ntpdate -u x2la01.hostigation.com >/dev/null" >>/etc/crontab
    echo "ntpdate -u x2la01.hostigation.com">>/etc/rc.local
    
  • letboxletbox Member, Patron Provider

    From main node

    vzctl set VMID --capability sys_time:on --setmode restart --save

    From your vps just use

    date --set="2012-7-17 12:26 pm"

    Update ""

  • RootRoot Member
    edited August 2012

    @key12 said: From main node

    vzctl set VMID --capability sys_time:on --setmode restart --save

    From your vps just use

    date --set="2012-7-17 12:26 pm"

    Update ""

    @key12: That also sets the clock on the main node and will in turn affect the time in all containers; as a host concerned about security, I wouldn't want just any VPS container having that sensitive capability.

  • krokro Member

    Great thread, lets expand on this for a momemt.

    Say a provder does decide to change the nodes time. What possible impact could this have on other containers already working with the incorrect time? Any?

  • RootRoot Member
    edited August 2012

    @kro said: Say a provder does decide to change the nodes time. What possible impact could this have on other containers already working with the incorrect time? Any?

    Timestamps in logs will change, but that's a given. Dovecot version 1.x is very sensitive to time changes and dies easily; this version is still used on cPanel&WHM servers (as of version 11.32). I believe Dovecot version 2.0 attempts to alleviate the problem and handles time changes better.

    If the host is just ensuring the correct time is set, I wouldn't worry too much about it assuming ntpd is configured and running. My understanding of ntpd is that it will very gradually adjust the clock as needed; this is in contrast to setting time via a cron job that will have a more immediate effect. If the clock is regularly (re)set via cron, I believe you'll find out soon enough if any daemons are very sensitive to time changes.

  • Say a provder does decide to change the nodes time. What possible impact could this >have on other containers already working with the incorrect time? Any?

    OpenVZ containers can have their system time updated without disruption/reboot. In my experience applications that are sensitive to accuracy will report that your system time has jumped by n seconds, then work correctly where they did not below.

    Having inaccurate system time is amazingly common with VPSs. In almost all cases I simply open a ticket pointing out the problem and the vendor corrects the time on the host. (Occasionally a naive tech will not understand the distinction between actual time and time zones. That requires a little education on my part.)

  • dmmcintyre3dmmcintyre3 Member
    edited August 2012

    I have had issues with MyBB's flood check after updating the time when the clock was more than a few min fast.

  • @swsnyder not sure why you would stay with someone that has a tech who doesn't understand the difference in a time zone and time on an openvz node. (Unless the person that is answering your ticket is in billing.)

  • I've got no problem working with someone who is willing to be educated.

    If you don't understand the difference between time and timezone, then I explain it, then you correct the problem, I'm happy. Problem solved.

    Nobody is born knowing this stuff, plus you're often dealing with someone whose first language is not English. Plus, lots of LEB vendors are running on a shoestring and can't keep techs, so there's a high turn-over rate. How much expertise are you buying for your $60/year?

    I rely on techs to be my hands for things I can't handle remotely. I don't rely on them to be my brain.

  • @swsnyder I would hope most startups would have some sort of technical background or partner with someone that does?

Sign In or Register to comment.