0

I am having recurrent problems with stalled datetime on my virtual Debian 8 machine running in Windows 8 Hyper-V. I haven't done much of a post-install configuration, it's a deliberately rather vanilla install and no fancy stuff -- I just use the box as a self-contained POSIX environment, logging in with PuTTY through SSH.

The date seems to "freeze" when the host sleeps and I wake it up after flipping the lid on host laptop after a day or so. The SSH session to the VM from PuTTy on Windows always remains intact. I didn't want to muck about with Hyper-V specific time synchronization services for Linux, I am content with using NTP. NTP has been installed with apt-get install ntp and initially I was getting the following with systemctl status ntp:

● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (running) since Mon 2017-08-14 23:16:55 CEST; 20h ago
  Process: 1167 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)
  Process: 1175 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ntp.service
           └─1184 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:115

Today after waking the laptop up and again observing the "frozen" date from yesterday, same command as above tells me the service has exited:

● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (exited) since Mon 2017-08-14 21:28:57 CEST; 1h 43min ago
  Process: 450 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)

Why does the service seemingly exit on its own? Apparently it exits as soon as the host thaws from sleep/hibernation. And with 0/SUCCESS of all things, letting me believe it behaves so by design and without encountering errors?

Once I systemctl restart ntp the process is back among scheduled processes and date is synchronized. Doing systemctl start ntp doesn't have same effect (maybe because it's already "loaded"/"active").

What's going on? Isn't NTP supposed to be running all the time, periodically synchronizing the clock as necessary when it drifts? Is this some Hyper-V related module in the kernel taking up on Microsofts recommendation not to use NTP with virtual machines, or maybe the network stack causes NTP to bail? Even though it's UDP and even SSH to the VM persists, so why would that be an issue?

/etc/ntp.conf, never edited it myself:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(6) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
  • Similar to this: superuser.com/questions/529144/… and this: serverfault.com/questions/10041/… – uSlackr Aug 15 '17 at 18:52
  • What does ntpd say in your system logs? – Paul Gear Aug 15 '17 at 21:32
  • @PaulGear Nothing -- journalctl -u ntp tells me there are no logged entries. /var/log/ntpstats is an empty directory. The only thing I found of interest is in syslog (/var/log/messages) telling me something about time drift too large. Googling made me understand that the virtual time just sort of remains after thawing the VM, and NTP aborts on abnormally large clock drift. So it all makes sense, but my takeaway from this is that NTP doesn't really help with virtual machines and I shouldn't even be using it. I will try to get time synchronization with Hyper-V integration services instead. – amn Aug 16 '17 at 11:33
  • journalctl will only show you recent messages; /var/log/messages is the right place to look. You still definitely need time sync in VMs - I prefer NTP, although if your accuracy requirements are low, you might find host time sync easier. – Paul Gear Aug 17 '17 at 12:28
2

By default, ntpd will exit if the system time is too far away from its calculated time. (I'm not sure what exit code it will use.) You can add the configuration directive tinker panic 0 to prevent it from exiting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.