On 28/11/18 8:51 am, Rick Stevens wrote:
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).
I suspect the time shift isn't an issue, as I'm starting the vpn's from
within KDE where I thought the time shift has already taken place, plus
journalctl seems to be indicating that the time shift has taken place
before chronyd has started.
The vpn I'm using, which operates through Openvpn, has servers all over
the world, and you configure it for the one you want to use. I've tried
the one closest to Australia that gives the best performance (being
Singapore) and the one they recommend (being Miami) and they both behave
the same way. The vpn is started, NetworkManager indicates the vpn is
"active" (by placing a lock icon on top of the network icon in the
system tray), it stays in that state for about 30 seconds according to
journalctl and then it logs a terminate message, and it takes about a
further 30 seconds for the vpn to actually shutdown.
I've changed a couple of parameters in the config, so I'll see whether
they have any impact, but at the moment I'm using Linux fairly infrequently.
regards,
Steve
<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
_______________________________________________
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
