Summary:	ASTERISK-03927: Registrations not tolerant of time changes
Reporter:	dsandras (dsandras)	Labels:
Date Opened:	2005-04-13 04:06:42	Date Closed:	2008-01-15 15:33:52.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Registration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-timereadme-head.patch.txt ( 1) bug4020.stable.patch.txt ( 2) readme_time.patch.txt
Description:	When your system is automatically adding one hour for the summer time, all phones are loosing their registrations for one hour. Asterisk should probably use its own internal counter instead of the system time to handle registrations. Reproducing it is easy, just add yourself one hour to your system and all your phones will be unregistered and unreachable at once.
Comments:	By: Brian West (bkw918) 2005-04-14 12:36:52 This is a very intresting bug. ;) By: Russell Bryant (russell) 2005-04-15 00:34:17 I have started working on this, but haven't figured out the correct fix yet. My working theory is that I think the issue is beyond chan_sip, it's in the scheduling system in sched.c.  We need to make it use offsets from GMT, so that a shift for daylight savings time doesn't mess us up. By: Mark Spencer (markster) 2005-04-15 00:44:58 If phones regregister within that hour this isn't an issue right? By: dsandras (dsandras) 2005-04-15 02:41:03 Indeed, but if they just registered before the hour change, you are without phone during nearly one hour. The workaround is to set the Expire time to 10 minutes so that you are without phone during 10 minutes maximum, but that will increase the load on the Asterisk side. By: Russell Bryant (russell) 2005-04-15 11:33:45 I guess ideally, we wouldn't be dependent on the time from the system clock at all, but this is going to be "non-trivial". By: Russell Bryant (russell) 2005-04-15 14:09:16 I have been looking at this for a while, and talking to other developers about it. The current method of scheduling uses UTC, so under any normal circumstances, there should not be a problem.  If you are manually changing the time, then you are going to have problems.  However, I wouldn't consider that normal operation, and there doesn't appear to be a way to work around that. I think this can be closed out as "unfortunately, we're not psychic enough to know what the sysadmin did to the clock".  :) By: dsandras (dsandras) 2005-04-16 06:40:32 I would just add that most voip servers I know are using NTP, and so there will be 2 hour changes by year, one for the summer, and one for the winter, during which all phones will be unregistered and unreachable during one hour. I'm not sure it has anything to do with the sysadmin. Whatever you do, you still have to change the hour for summer and winter time, be it automatic via NTP or manual via the sysadmin. I wouldn't consider that bug as not important, but it is your choice. By: nick (nick) 2005-04-16 11:56:22 Set your system clock to use UTC. Set your offset for your location. Use NTP to keep the time in sync. Your system time won't make any large jumps if you set it up this way. Nick By: Russell Bryant (russell) 2005-04-16 13:49:55 Maybe we should add a note to a README somewhere that points out this issue. By: nick (nick) 2005-04-16 16:37:25 How about that? DOF Nick By: Jeffrey C. Ollie (jcollie) 2005-04-16 17:05:26 NTP **DOES NOT** change the kernel's run time clock for daylight savings time.  The UNIX kernel and NTP run on UTC, which does not have daylight savings time.  The "time jump" that you see when daylight savings takes effect is merely a change in how the C library *displays* the time to the user. Actually changing the time (with date(1) or similar) will cause discontinuities in the time and will mess up *any* application that uses time (and therefore shouldn't be done). By: nick (nick) 2005-04-17 00:42:01 Some systems don't default to UTC for the system clock, like Red Hat 9.  Despite the fact that Unix time is kept since 1 Jan 1970, if the system clock is on local time, and the local time changes without the offset changing, the number of seconds since the epoch will change.  But now that I write that, it seems like the offset should change right when DST starts too, so the seconds since epoch shouldn't change, I don't think. But I also see http://forums.gentoo.org/viewtopic.php?t=33607, which basically agrees with what I was saying. Hrm. Now I'm not so sure... -A confused NB By: Jeffrey C. Ollie (jcollie) 2005-04-17 07:29:11 The "system clock" that you refer to is a hardware clock in your PC that keeps the time even while your PC is turned off.  And you are right that the hardware clock typically runs on local time because that's what Windows expects.  However, Linux (and probably other UNIXes) only read the hardware clock once upon bootup to initialize the kernel's internal clock.  Once your system is booted, the kernel never reads the hardware clock again.  The kernel's internal clock is maintained through the use of timer interrupts.  For more information see "man hwclock(8)". By: nick (nick) 2005-04-17 10:58:40 No, I refer to the clock kept by the hardware as the "hardware clock." And yes, you're right, the hardware clock is only read on bootup and resynced on shutdown. I think what this comes down to is "make sure your system is set up properly or stuff could go wrong." Based on the OP's problem, I'd say this problem can exist somehow. As a matter of practice, system time should be kept as UTC on servers and the offset should be calculated through the use of TZ. While not doing this may work on some Unices under some conditions, it obviously _can_ break stuff, even if it doesn't for you or I. Nick By: Jeffrey C. Ollie (jcollie) 2005-04-17 11:28:13 It's not just a matter of practice.  The Linux kernel always runs on UTC.  The TZ environment variable only affects how the C library translates UTC to/from the user and the kernel.  You shouldn't need to be using date(1) to update the time.  If your system is connected to the internet use NTP to keep the time synchronized.  If your system is not connected to the internet use NTP to talk to a GPS unit or other source of accurate time. By: Mark Spencer (markster) 2005-04-17 12:48:14 Fixed in CVS head, thanks! By: Jeffrey C. Ollie (jcollie) 2005-04-17 19:11:35 I think that the wording of the README patch is inaccurate.  I've attached a patch with a different wording that I believe is more accurate. By: goatmilk (goatmilk) 2005-05-09 22:49:02 bug4020.stable.patch.txt ready for stable commit. By: Russell Bryant (russell) 2005-05-10 00:04:24 added to 1.0, thanks goatmilk! Although there is obviously no intellectual property issues with your patch, it is generally a good idea to always mention your disclaimer when you upload a patch.  It also gets you an extra karma point!  :) By: Digium Subversion (svnbot) 2008-01-15 15:31:51.000-0600 Repository: asterisk Revision: 5482 U   trunk/README ------------------------------------------------------------------------ r5482 | markster | 2008-01-15 15:31:51 -0600 (Tue, 15 Jan 2008) | 2 lines Note that big time changes can cause issues (bug ASTERISK-3927) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5482 By: Digium Subversion (svnbot) 2008-01-15 15:32:06.000-0600 Repository: asterisk Revision: 5497 U   trunk/README ------------------------------------------------------------------------ r5497 | kpfleming | 2008-01-15 15:32:05 -0600 (Tue, 15 Jan 2008) | 2 lines more clarification of time changes and how they affect Asterisk (bug ASTERISK-3927) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5497 By: Digium Subversion (svnbot) 2008-01-15 15:33:52.000-0600 Repository: asterisk Revision: 5617 U   branches/v1-0/README ------------------------------------------------------------------------ r5617 | russell | 2008-01-15 15:33:52 -0600 (Tue, 15 Jan 2008) | 2 lines add note about the effects of time changes (bug ASTERISK-3927) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5617