| gry | Incorrect time. Stuck on Friday the 18th. Where can I check the ntp server sync settings? | 01:50 |
|---|---|---|
| gnarface | in /etc/ntpd.conf | 01:51 |
| gnarface | i think | 01:51 |
| gnarface | either that or with ntpq | 01:51 |
| gnarface | oh sorry it's /etc/ntp.conf | 01:52 |
| gnarface | you should be able to check current status with ntpq | 01:53 |
| brocashelm | ntpq -p shows your peers list | 01:54 |
| brocashelm | i use ntpsec, so i noticed my ntp.conf was in a subfolder (/etc/ntpsec) | 01:55 |
| gry | gnarface, brocashelm, https://dpaste.com/97W92JK3A.txt | 02:04 |
| rwp | Hi gry! Your ntp daemon is in sync but probably the time is so far off that it cannot skew it fast enough. | 02:06 |
| rwp | Instead you will need to run ntpdate *once* to jump the date to the current time. And then restart ntpd. All will be good after that point. | 02:07 |
| rwp | Let me look up the ntpdate command to jump the time. Jumping the time is discouraged and generally a reboot is recommended. | 02:07 |
| rwp | At boot time the system clock is set from the hardware clock. So it always starts out close enough for ntp to skew it on time. Usually within 4 useconds. | 02:07 |
| rwp | Oh, ntpdate is deprecated now. It's done with an "ntpd -g" now. Try restarting ntpd and seeing if it does the right thing. "sudo service ntp restart" | 02:09 |
| brocashelm | ntpdate works for me (ntpsec installed) | 02:09 |
| rwp | It's not part of "ntp" package anymore. (I knew that. But I forgot it until I was reminded of it.) | 02:10 |
| brocashelm | oh, i see what you mean now | 02:10 |
| brocashelm | thanks, i'll use that command | 02:11 |
| brocashelm | is it normal for ntp/ntpsec to take its sweet time while restarting? needrestart will still prompt me for it even after doing so | 02:11 |
| rwp | I haven't noticed restarting problems. | 02:11 |
| rwp | It might be slowed up by the DNS resolving the multiple "pool" addresses. | 02:12 |
| brocashelm | it restarts, but takes a while | 02:12 |
| rwp | In rough terms about how long is a little while? | 02:13 |
| brocashelm | like 2-3 minutes | 02:13 |
| brocashelm | once it says "starting ntpd" | 02:13 |
| rwp | I think it is starting okay but not reporting any sync data until it has a few polls of the configured servers. It doesn't know anything about jitter for at least a few poll cycles. | 02:14 |
| rwp | It starts out with a 64 second polling cycle. And then if the higher stratum sources are stable enough it backs off the polling time. | 02:15 |
| rwp | My polling time on my systems right now are showing 1024 seconds polling time. Because they are all interconnected and the connection is stable. | 02:15 |
| brocashelm | ah | 02:15 |
| rwp | An interesting part of the ntpp -q output is the "reach" column. It's an octal bitmap. 377 is octal 377 showing the status of the last 8 poll attempts. 1 is success 0 is lost packet. It's a shift register. | 02:17 |
| rwp | So a value such as 54 is octal 54 and shows a high packet loss to that server. A 377 is all packets good. But 17 or other is all good *so far* as it is filling the shift register from right to left and shifting in the 8 bits of status. | 02:18 |
| gry | http://st22.uk.to:3000/file/1/k7GFDFTP0A8da3ww | 03:11 |
| gry | rwp, --^ pastebin | 03:12 |
| joerg | >> -x, --slew Slew up to 600 seconds. Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 | 03:38 |
| joerg | s. Thus, an adjustment as much as 600 s will take almost 14 days to complete.<< | 03:38 |
| gry | Didn't interpret that. Could you rephrase, please? | 03:40 |
| joerg | it's an excerpt of `man ntpd` | 04:32 |
| joerg | probably also relevant is this section: man ntpd|less +'/Most operating ' | 04:34 |
| joerg | and finally I always found hwclock a valuable command too | 04:36 |
| joerg | the above boild down to: it may take up to 128ms / 0.5ms/s = 256s until systime is in sync with UTC again | 04:40 |
| joerg | it's mindboggling how many broken concepts to handle netdate and systime and cmos time linux suffered over the years, and still it seems there are problems | 04:48 |
| joerg | line #3 in your pastebin is an error msg | 04:53 |
| gry | joerg, what would you suggest to do? | 05:20 |
| gry | I only understood the kernel cannot fix the time, it would take it 14 days. I didn't understand anything else. | 05:20 |
| joerg | I have no idea :-) | 05:20 |
| joerg | wait, the kernel can't fix the time? | 05:20 |
| joerg | why? | 05:21 |
| joerg | try `date; hwclock; date; hwclock` | 05:22 |
| joerg | `cat /var/lib/ntp/ntp.drift` | 05:23 |
| joerg | according to manpage ntpd is supposed to adjust systime by skew for an offset of <128ms, otherwise it skips | 05:25 |
| joerg | ntpd is an intricate thing meanwhile | 05:28 |
| joerg | we'd need more info than just >>[21 Mar 2022 01:50:42] <gry> Incorrect time. Stuck on Friday the 18th.<< to start diagnosing what's going haywire | 05:29 |
| joerg | if your time actually is stuck at 2022-03-18 and not running then you most certainly have a hw problem, likely weak cmos battery | 05:32 |
| gry | joerg, on it. Command 'hwclock' not found. Package 'hwclock' does not exist. What's up next? | 05:38 |
| gry | joerg, it is a virtual guest. The host's time is fine. | 05:38 |
| gnarface | gry: is the timezone correct in the guest? | 14:29 |
| gry | gnarface, how do I check? | 21:45 |
| fsmithred | gry, look in /etc/timezone | 21:51 |
| fsmithred | 'dpkg-reconfigure tzdata' to change it | 21:52 |
| gry | "America/New_York" | 21:52 |
| fsmithred | that's UTC-4 right now. | 21:52 |
| gry | I don't mind if it's wrong; I do mind that it is 3-4 days behind, even NY doesn't have that. | 21:52 |
| fsmithred | in US | 21:52 |
| fsmithred | days? | 21:52 |
| gry | "Fri 18 Mar 2022 09:14:49 PM EDT" is wrong. | 21:52 |
| fsmithred | are you using ntp or something else to sync to a time server? | 21:53 |
| fsmithred | gry, hwclock must be run as root. It's part of the util-linux package. It is installed. | 21:58 |
| fsmithred | hm... my hardware clock was 2 minutes behind system clock. I fixed that a couple months ago when it was 10 minutes off. The computer does not get turned off. What could be wrong? | 22:05 |
| used____ | Nothing is wrong, the accuracy of the hw clock on a computer is not stellar. | 22:07 |
| used____ | 20 seconds / month or more drift are normal | 22:07 |
| gry | "hwclock: select() to /dev/rtc0 to wait for clock tick timed out" | 22:07 |
| used____ | Make that 50 seconds / month unadjusted | 22:08 |
| gnarface | seems weird | 22:08 |
| used____ | Why? | 22:08 |
| gnarface | being days off i mean | 22:08 |
| fsmithred | yeah | 22:09 |
| gnarface | yea maybe rtc driver problem? | 22:09 |
| gnarface | not sure | 22:09 |
| fsmithred | bunch of google hits on that error message | 22:09 |
| used____ | 30*86400 = 2592000 seconds/month; typical undajusted clock quartz is 20ppm, so 2592000 * 0.00002 = 51.84000 seconds off | 22:09 |
| used____ | Days off is typically caused by never-ran ntp and or a few days of downtime unaccounted for. | 22:10 |
| eyalroz | So, something bad happened to me today... | 22:10 |
| used____ | You woke up? ;) | 22:10 |
| used____ | Sorry this is not *-offtopic ;) | 22:10 |
| eyalroz | used____: I'm not that far gone :-( | 22:10 |
| eyalroz | I came back after a few hours outside, and the Cinnamon screensaver was stuck on some earlier hour | 22:10 |
| eyalroz | and would not go away with keypresses, | 22:11 |
| eyalroz | although moving the mouse worked | 22:11 |
| eyalroz | I could also switch to another VT and run terminal sessions | 22:11 |
| used____ | It crashed! I never saw a software crashed screensaver, only on bad hardware which froze in many other contexts | 22:11 |
| eyalroz | I was wondering... is there any way I could continue my desktop environment session from that situation, somehow? | 22:11 |
| eyalroz | I tried killing the screensaver, which worked, but it didn't get me my desktop back | 22:12 |
| used____ | Well in xfce4 you can find the PID of the saver and kill it | 22:12 |
| eyalroz | eventually I gave up and restarted lightdm | 22:12 |
| eyalroz | used____: I found the saver's pid and killed it, | 22:12 |
| eyalroz | but that wasn't enough | 22:12 |
| used____ | But as you noticed it does not always help | 22:12 |
| eyalroz | yeah | 22:12 |
| used____ | Try some stress test on your hw | 22:12 |
| used____ | See if it freezes at any time. | 22:13 |
| eyalroz | used____: I might, but that's not the point | 22:13 |
| eyalroz | What I was wondering if whether some recipe for getting Cinnamon to "take over" again, show windows, the panel, etc. | 22:13 |
| eyalroz | Because everything was running | 22:13 |
| used____ | If an "integrated" wm crashes, there is probably no way to restart it with state. | 22:13 |
| eyalroz | used____: But the thing is, it didn't crash | 22:13 |
| used____ | In xfce4 the saver is a separate process which can be killed safely | 22:13 |
| eyalroz | I mean cinnamon was running, my browser was running etc. | 22:13 |
| used____ | How did you determine it was running? | 22:14 |
| eyalroz | used____: cinnamon's wm is not integrated. | 22:14 |
| fsmithred | eyalroz, maybe vnc in from another box? | 22:14 |
| eyalroz | I ran pstree and saw it | 22:14 |
| eyalroz | fsmithred: I didn't have a vnc server running. I was hoping for a same-box approach | 22:14 |
| used____ | pstree or top or ps auxwf shows you pids, not whether they are running | 22:14 |
| eyalroz | I also did htop and check CPU usage of stuff | 22:15 |
| eyalroz | and it looked like what I would expect, | 22:15 |
| used____ | Did you note in what state they were? Busy spinning is a way to get stuck while showing "running" | 22:15 |
| used____ | ps auxwf and top shows running state. | 22:15 |
| eyalroz | used____: So, I should have checked, but I didn't. | 22:16 |
| used____ | ps auxwf columb STAT | 22:16 |
| eyalroz | Let's suppose for discussion's sake their status was running rather than anything else | 22:16 |
| used____ | Chances are something posted a modal dialog under the saver | 22:16 |
| used____ | If everything ran. Which is unusual. And that would not block the clock display on the saver. | 22:17 |
| used____ | So, imo, the saver crashed. Period. | 22:17 |
| eyalroz | Ok, the saver crashed. But could I have, in that situation, poked the session manager or window manager process to put things back in working order? | 22:18 |
| used____ | Unlikely. Save session frequently if you suspect something does not work nicely. | 22:19 |
| used____ | Ok, time to "vanish" here. | 22:19 |
| * used____ uses the novel stealth shield to vanish | 22:19 | |
| Xenguy | I never expect true stability from *any* OS anymore... | 22:28 |
| Xenguy | Just today, I sat down in the morning to send a very important email, and *something* went wrong, and the whole system completely locked up -- nothing... | 22:29 |
| Xenguy | So, press the power button for 5 seconds and start over, simple fact of life | 22:29 |
| fsmithred | try sysrq keys before power button | 22:30 |
| Xenguy | fsmithred, I'm not sure what that is on my keyboard here, but I've heard the term before | 22:37 |
| fsmithred | hold down alt-sysrq(prnt-screen) and press and release in order: R S U B | 22:38 |
| fsmithred | (E and I no longer work) | 22:38 |
| fsmithred | oh, you might have to edit /etc/sysctl.conf first. | 22:39 |
| fsmithred | kernel.sysrq=1 | 22:39 |
| fsmithred | default setting is 438 | 22:39 |
| fsmithred | look up other sysrq keys. b is reboot, o is poweroff | 22:40 |
| fsmithred | Sync, Unmount | 22:40 |
| eyalroz | Xenguy: Are you sure it was _completely_ locked up? | 22:41 |
| eyalroz | Did you try something like Ctrl+Alt+Fn keys, to switch VTs? | 22:41 |
| eyalroz | Sometimes that works when other things don't | 22:41 |
| eyalroz | Anyway, fsmithred: Question for you, following my last one. Now that I've restarted mi lightdm, most things work fine, but I can't play video. It's as though some kind of resource or lock wasn't released, and video players can't get a hold of it anymore in the new session. Any idea of how I might resolve that? | 22:43 |
| Xenguy | eyalroz, Yeah, I always try diving to a VT, cos I always have top running as root, but the system didn't respond... | 22:44 |
| Xenguy | I'll have to look up this 'sysrq' thing I suppose | 22:44 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!