MyCloud "ntpd" is AWOL... time initially sync's but won't stay sync'd

My Cloud OS 3 Personal & Network Attached Storage My Cloud
1

My 2TB MyCloud doesn’t have “ntpd” running on it.  In fact, it doesn’t even have an executable for “ntpd”.

Interestingly, it does *initially* synchronize time with the Linux machine on my LAN if I add the entry “192.168.1.3” to the server pool (here’s the line from  /etc/ default/ntpdate ) :

NTPSERVERS=“192.168.1.3 time.windows.com pool.ntp.org”

More interestingly, while there is no “ntpd” there *are* “/usr/sbin/ntpdate” and “/usr/sbin/ntpdate-debian”, which does

appear to be getting started by “init”.  But it seems like what it does is sync the time - successfully - with the server on 192.168.1.3, and then exits without starting any sort of “Daemon” on the MyCloud.

I discovered this when the time on the MyCloud wandered out of sync, and I successfully ran “invoke-rc.d ntpdate start” andit *did* resynchronize…  But there’s still no obvious *Daemon* running, and I can only assume it will probably wander out of sync again (which, for anyone who doesn’t know why I’m obsessed with this, is a Bad Thing if you’re using a system as a backup server as I am.)

here are some lines from /var/log/daemon.log :

Jul 12 23:56:13 WDMyCloud ntpdate[10074]: Can’t find host time.windows.com: Name or service not known (-2)
Jul 12 23:56:53 WDMyCloud ntpdate[10074]: Can’t find host pool.ntp.org: Name or service not known (-2)
Jul 12 23:54:07 WDMyCloud ntpdate[10074]: step time server 192.168.1.3 offset -172.228438 sec

The MyCloud can’t reach the Internet from inside my LAN (deliberately), so no surprise on the other two servers.

Meanwhile…  trolling around on the net turns up the fact that “ntpdate” is deprecated *and* that “ntpd” has been in Debian as far back as I can remember (and “ntpdate” has not - in fact I think it’s a USB program?) …

So, before I go on a massive debugging binge, I thought I’d ask if anyone here knew about this…  is there supposed to be a time server running on the MyCloud, and what is its name, and why is WD using the (supposedly deprecated) “ntpdate”, and - most importantly - why am I not getting periodic time sychronization?  …  Etc…

2

diagoras wrote:

 Meanwhile…  trolling around on the net turns up the fact that “ntpdate” is deprecated *and* that “ntpd” has been in Debian as far back as I can remember (and “ntpdate” has not - in fact I think it’s a USB program?) …

I don’t know where you’re getting that info, but it’s just simply outright false…

ntpdate is NOT deprecated – it’s being phased out – but not yet.

No, there’s not supposed to be a time server running on the My Cloud – only the NTP client, ntpdate.

https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

cron runs ntpdate every day.

The reason your clock was three minutes out of sync is because you didn’t have a valid set of servers defined in the GUI.

3

OK…  I wondered about that.  So *all* of the entries have to be accessable when it starts or it won’t start the “ntpdate” client?  I wouldn’t think they’d do *that*…  but, whatever…  and it did sync when I ran it from the CLI

Wankipedia claims it’s deprecated

https://en.wikipedia.org/wiki/Ntpdate

also this man page

https://www.freebsd.org/cgi/man.cgi?query=ntpdate&sektion=8

(I couldn’t find a man page for it on any of my Debian systems; they only have ntpd)

So, “ntupdate” is a client only…  maybe that explains it.  What you normally do is

point the ntpd server on one machine at the ntpd server on another, with an entry like

server 192.168.1.3

in the /etc/ntp.conf file…  But I’m sure you know all that.

4

diagoras wrote:

OK…  I wondered about that.  So *all* of the entries have to be accessable when it starts or it won’t start the “ntpdate” client?

No, where’'d you get that idea?   

As you said, it worked after you added a valid, reachable entry…

It also started (but aborted) when there were none, since there were no servers it could use to update with.

5

OK…  maybe I didn’t explain the sequence of events clearly.

Out of the box, there are some entries for ntp servers, but because I didn’t enable Internet access, it didn’t set the clock right.

Then from the “dashboard” I added the address of the local machine that’s running “ntpd” - leaving the original entries for the NTPD pool etc. in there  as well - and it set the clock right (I also had to enter the same machine’s address as the “gateway”.

Then several days later I noticed that the time had drifted, indicating that “ntpdate” hadn’t been  successfully run again since that first time when it set the clock.  So I ran it again via “update-rc.d” and it again corrected the clock - and I noticed that “ntpd” wasn’t running.

So, when you said it was aborting because I didn’t have a valid entry, I did have a valid entry but the other entries were *not* valid, so I thought you meant it was aborting because of those, even though I had one valid entry…

Anyway, now I realize that what’s happening is that there’s no server, and “cron” is just running “ntpdate” once a day to resync the clock…  and I don’t think it’s running successfully, because I don’t see the log messages in /var/log/daemon.log (though it hasn’ t drifted noticeably yet either).

But, you know what…  before I spend any more of anybody’s time on this, I *just* discovered that - additionally - both /tmp and /var/log are 100% full:

some lines of output from “df -k”:

tmpfs 102400 102400 0 100% /tmp
/dev/root 1968336 685956 1182392 37% /var/log.hdd
ramlog-tmpfs 20480 20480 0 100% /var/log

and there are a *ton* of really bizarre files getting created and messages getting logged, that are clogging them up…  So I had probably better go fix that first…  just about anything else including the “cron” job that runs “ntpdate” could be failing as a result of not being able to write to the logfiles, etc…

6

OK…  I’ve at least isolated the bug that’s filling up /tmp and /var/log (there’s a separate thread on that), and can work around it for the moment.

But I’m still not seeing “ntupdate” getting run by “cron”.  “ntupdate” does log to “daemon.log” when it’s run by “init”, so I"m assuming I should see log entries there if it’s getting run by “cron”?  (And, the clock has drifted 2 seconds since

yesterday).

I guess I can go turn on debug logging for “ntupdate”…  Or Something…  ??  It has to be either “run-parts” or “cron” itself that’s giving up, because “ntupdate” *does* work when it runs at reboot…

7

Yep, mine runs at 3:00am every day…

daemon.log:Jul 14 03:00:17 CloudNAS ntpdate[19156]: step time server 23.101.187.68 offset -2.072034 sec
daemon.log:Jul 15 03:00:16 CloudNAS ntpdate[5343]: step time server 67.18.187.111 offset -2.054272 sec
daemon.log.1:Jul 12 03:00:19 CloudNAS ntpdate[9082]: step time server 198.110.48.12 offset -2.066894 sec
daemon.log.1:Jul 13 03:00:17 CloudNAS ntpdate[25196]: step time server 38.229.71.1 offset -2.056187 sec

8

OK…  the problem “went away” and it’s started working, after a comedy of errors on my part (I had clobbered “crontab”, for one thing).

However, I really think the original problem was /var/log and /tmp  filling  up as I mentioned in this post here

http://community.wd.com/t5/WD-My-Cloud/2-TB-MyCloud-filesystems-quot-tmp-quot-and-quot-var-log-quot/m-p/887698/highlight/false#M36995

That was causing all manner of stuff to fail, including either the “cron” job that runs “ntpdate”, or something else earlier in the “run-parts” sequence which was in turn causing the “cron.daily” job to abort.

Meanwhile though, I’ve got “cron” instrumented up the yin-yang so it logs every… last…**bleep**…thing that comes out of “cron” and all of its children, grandchildren, cats, dogs, and fleas…  which as you probably know (but I didn’t) is *not* straightforward (I’m somewhat appalled, but I’ll get over it…).  So if the problem comes back I’ve got a trap set for it.