From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- open_issues/pfinet_vs_system_time_changes.mdwn | 101 ------------------------- 1 file changed, 101 deletions(-) delete mode 100644 open_issues/pfinet_vs_system_time_changes.mdwn (limited to 'open_issues/pfinet_vs_system_time_changes.mdwn') diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn deleted file mode 100644 index 09b00d30..00000000 --- a/open_issues/pfinet_vs_system_time_changes.mdwn +++ /dev/null @@ -1,101 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_hurd]] - - -# IRC, unknown channel, unknown date - - I did a sudo date... - and the machine hangs - -This was very likely a misdiagnosis. - - -# IRC, freenode, #hurd, 2011-03-25 - - antrik: I suspect it'S some timing stuff in pfinet that perhaps - uses absolute time, and somehow wildely gets confused? - tschwinge: BTW, pfinet doesn't actually die I think -- it just - drops open connections... - perhaps it thinks they timed out - antrik: Isn't the translator restarted instead? - don't think so - when pfinet actually dies, I also loose the NFS mounts, which - doesn't happen in this case - hehe "... and the machine hangs" - he didn't bother to check that the machine is perfectly fine, only - the SSH connection got dropped - Ah, I see. So it'S perhaps indeed simply closes TCP - connections that have been without data for ``too long''? - yeah, that's my guess - my clock is speeding, so ntpdate sets it in the past - perhaps there is some math that concludes the connection have been - inactive for -200 seconds, which (unsigned) is more than any timeout :-) - (The other way round, you might likely get some integer - wrap-around, and thus the same result.) - Yes. - - -# IRC, freenode, #hurd, 2011-10-26 - - anyways, when ntpdate adjusts to the past, the connections hang, - roughly for the amount of time being adjusted - they do not die though - (well, if it's long enough, they probably timeout on the other - side...) - - -# IRC, freenode, #hurd, 2011-10-27 - - oh, another interesting thing I observed is that the the subhurd - pfinet did *not* drop the connection... only the main Hurd one. I thought - the clock is system-wide?... - It is. - it's really fascinating that only the pfinet on the Hurd instance - where I set the date is affected, and not the pfinet in the other - instance - - -# IRC, freenode, #hurd, 2012-06-28 - - great, now setting the date/time fucked my machine - yes, we lack a monotonic clock - there are select() loops that use gettimeofday to determine how - much time to wait - thus if the time changes (eg goes back), the calculation goes - crazy - pinotree: didn't you implement a monotonic clock?... - started to - bddebian: did it really fuck the machine? normally it only resets - TCP connections... - yeah, i remember such gettimeofay-based select-loops at least in - pfinet - I don't think it's a loop. it just drops the connections, - believing they have timed out - antrik: Well in this case I don't know because I am at work but - it fucked me because I now cannot get to it.. :) - bddebian: that's odd... you should be able to just log in again - IIRC - - -# IRC, freenode, #hurd, 2012-07-29 - - pfinet can't cope with larger system time changes because it can't - use a monotonic clock - -[[clock_gettime]]. - - well when librt becomes easily usable everywhere (it it's - possible), it will be quite easy to work around this issue - yes and no, you just need a monotonic clock and clock_gettime - able to use it - why "no" ? -- cgit v1.2.3