Quoting tuxd3v@??? (tuxd3v@???):
> 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.)