On 11/27/18 12:48 PM, Stephen Morris wrote: > On 27/11/18 10:53 am, Rick Stevens wrote: >> On 11/26/18 1:46 PM, Stephen Morris wrote: >>> On 21/11/18 10:02 am, Rick Stevens wrote: >>>> On 11/20/18 2:09 PM, Ed Greshko wrote: >>>>> On 11/21/18 5:07 AM, Stephen Morris wrote: <snip old stuff> >> A second, smaller time jump will appear once chronyd actually syncs the >> system clock to true UTC (indicated by that "stepped by" bit in the >> logs). Once that happens, then log entries will be accurate from that >> point onwards and chronyd will do its best to keep the system clock >> synced to UTC. Keep in mind that journalctl will assume ALL log entries >> have a UTC timestamp, regardless of when the clocks got mangled and this >> is the cause of the time shifts in the display. The radical change in >> system clock when it switches from local time to UTC time MAY cause >> programs to malfunction, since they assume that the system clock was in >> UTC. This _may_ be why your VPN was disconnecting...it assumed there was >> no traffic for whatever the difference is between your local time and >> UTC, so it disconnects. > > I can understand the time sync causing a problem with the VPN, but the > question I have is why now? Its probably 12 months since the last time I > ran the VPN, so it would have been in F27 and earlier where the VPN was > actively being used and there were no issues with the bios clock being > set to local time, which is how I've been running the bios time settings > for over 30 years, except for once when I did try it set to GMT and > Windows couldn't handle it, but also having said that I haven't been > running Linux for that long, I've only been running it at home for 10 or > so years and I have always at least dual booted. > > Could my issue be that this time shift issue has always been present but > its only now that it is becoming obvious? It's possible. It's also possible that the VPN client (vpnc, whatever) uses a different default timeout setting now. The old one worked OK, the new one requires you override it in the config. It also may be that the VPN server has been updated and doesn't like something. As I said, this clock thing _may_ explain the VPN dropout. I just don't know. The only way to know is if the reason generates log entries (and we hope it does). In that case, you may need to look at ALL of the log entries. If the dropout occurs somewhere near when the timestamps get funky, that's a good indication that the clock changes are causing it. Just why should be revealed in the log entries. I'm just spitballing this. The cause may be totally unrelated. As always, troubleshooting sporadic things of this nature remotely (even locally) is difficult--especially when you can only look at one end of the connection (VPN server logs, if available, would be useful). <snip more stuff> ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Sarchasm: The gulf between the author of sarcastic wit and the - - reader...who doesn't get it. - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
