Quoting tux...@sapo.pt (tux...@sapo.pt): > problems with rtc clock are not uncommon, the need for a power > cycle, seems to be.. > > This discrepancies, in the date, .. how many days it takes to > happen, does you have any Idea? > does the Boards are properly powerup?I mean suficient levels of > Voltage/Current.. > > Try to update the date with something like 'ntpdate ntp_server_ip' > And see is that helps, if yes then you can run it via a cronjob, > from time to time..
If running ntpdate, depending on how much skew there is from correct time, you might need the '-B' option. Quoting the man page: -B Force the time to always be slewed using the adjtime() system call, even if the measured offset is greater than +-128 ms. The default is to step the time using settimeofday() if the offset is greater than +-128 ms. Note that, if the offset is much greater than +-128 ms in this case, that it can take a long time (hours) to slew the clock to the correct value. During this time, the host should not be used to synchronize clients. I should also mention that ntpdate being increasingly unmaintained and crufty means that the 'sntp' or 'ntpd' utilities with appropriate options are now better long-term tools. https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate I think 'ntpd -gq' will do the trick. Or 'sntp -s <IP>'. 'ntpd -gq' will fail if the ntp daemon is binding to the service port, but ISTR you can supply '-u' to work around that. (Above is from memory, not tested.) _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng