Brand new, clean install on FreePBXHosting.com
System & Modules updated to current. System rebooted.
Even after being online for an hour, it says Asterisk has been running for 7 seconds.
And the updated time is negative.
Going down. It is counting down from something.
Is there some setting that got set someplace before a timezone was changed or something?
What does
echo $(($(date -d "$(sudo hwclock)" +%s) - $(date +%s) ));date
return on the cyberlink vm (no timezones in play here for the first bit, revealed on the second) ?
hwclock -c (no sudo needed for root) will show any diffs, hwclock -w sets hardware to kernel time (a good thing)
hwclick -s sets kernel time to hwclock ( a bad thing)
I had a similar issue some time ago installing the distro. FWIW:
Here is what the cyberlink vm returns:
> $(($(date -d "$(sudo hwclock)" +%s) - $(date +%s) ));date
[sudo] password for xxx:
21598
Fri Jan 29 20:46:06 CST 2021
Generally i prefer to keep my linux hwclocks are set to UTC but not an option with a vm , generally the system time is set to the hwclock by the kernel when booting, i would double check your locsl time is correctly set to a NTP service before starting FPBX
The problem went away after it counted to 0.
Well after it reached zero it said Asterisk was not there. This is common enough. a quick fwconsole restart resolved that.
The clock is in CST it seems? Or does the date reflect the settings that were made withing FreePBX? because that was all set to CST
But that does not resolve where it came from in the first place.
There are two clocks , one is the system clock that starts at 0 on boot, the other is the RTC , in hardware it is a battery backed device that runs even when the hardware is powered off, this device is conventially set to UTC , it is not particularly accurate so soon after the network is up the OS will start to synchronize the rtc and the internet time, offset by the local timezone, against UTC and thus set the ‘system clock’, Of course this /dev/rtc is virtualized in a vm, so if the rtc is set to wisconsin time, and services start such that system time is not fully set, ( time is not set in one jump but slewed over many ‘jiffy’s ) then the time might not be totally predictable for a while . By delaying FPBX’ start by a few seconds that possible race condition can be avoided. A better way with systemd services is for ‘unit’ to start
After=systemd-time-wait-sync.service
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.