From suha@sac.sfbay.sun.com Fri Sep 25 10:15:06 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PHF5QA012005 for ; Fri, 25 Sep 2009 10:15:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8PHF4KW026390; Fri, 25 Sep 2009 10:15:05 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00K07EL4BE00@brm-avmta-1.central.sun.com>; Fri, 25 Sep 2009 11:15:04 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00H6YEL2UE30@brm-avmta-1.central.sun.com>; Fri, 25 Sep 2009 11:15:03 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PHF2C2009333; Fri, 25 Sep 2009 10:15:02 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PHEMJd011994; Fri, 25 Sep 2009 10:14:22 -0700 (PDT) Received: (from suha@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n8PHELm8011990; Fri, 25 Sep 2009 10:14:21 -0700 (PDT) Date: Fri, 25 Sep 2009 10:14:21 -0700 (PDT) From: Suhasini Peddada Subject: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] To: PSARC-ext@sun.com Cc: Nobutomo.Nakano@sun.com Message-id: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3819 I am submitting the fasttrak for Nobutomo and seeking a patch binding. Time out is Oct 2nd, 2009. Thanks, -Suha Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Timezone cache renewal 1.2. Name of Document Author/Supplier: Author: Nobutomo Nakano 1.3 Date of This Document: 25 September, 2009 4. Technical Description Name ---- Timezone cache renewal in ctime(3C) (aka No reboot on timezone update) Background ---------- Timezone patches contain the updates of the zoneinfo database files. Internally libc caches the timezone information and never rereads it. This means that when the timezone patches are applied and updates are made to the zoneinfo database, files they are not activated until the system is rebooted or the various process that use the timezone information are restarted. The impact of a reboot for the changes in the timezone is significant especially for those customers with many Sun servers running many domains. Customers have requested that when applying timezone patches, a reboot is not required. To satisfy the requirement, the timezone code could check if the zoneinfo database files have been updated since the last time by issuing the stat(2) system call. However, as stat() is an expensive system call, the addition of the stat() call would result in a great performance regression in the timezone code in libc. Therefore, a more efficient method that notifies libc that the zoneinfo database has been updated needs to be introduced. Proposal -------- All the ctime(3C) and mktime(3C) functions will use a semaphore on per zone shared memory pages. The semaphore can be attached to process by using mmap(2) to a software driver. The software driver allows mmap() to attach the shared memory page for semaphore, and also allows a privileged ioctl (requires PRIV_PROC_OWNER) to modify the memory contents(semaphore) for the zone. The software driver also allows to modify the memory contents for all zones (additionally requires PRIV_PROC_ZONE). The reason for using a software driver is solely to protect the shared memory from being released, invalidated or corrupted. The ctime(3C) and mktime(3C) functions will test the semaphore before using cache'd timezone information and, if it has changed, purge the cache and re-read the zoneinfo file. No privilege is required to test the semaphore. If the libc failed to open the device file, ctime(3C) and mktime(3C) will not cache the timezone information. When zoneinfo database files are updated, a new utility tzreload(1M) can be executed, by a privileged user, to propagate the change (update the semaphore status on the shared memory). All subsequent calls to ctime(3C) functions from any processes within the system will reread the updated zoneinfo database file. tzreload command will be added to the "Process Management" RBAC profile. Interfaces ---------- NAME STABILITY DESCRIPTION ------------------------------------------------------------------- TZSYNCIOC_INC Consolidation Private ioctl to increment semaphore value. TZSYNCIOC_INC_ALL_ZONES Consolidation Private ioctl to increment semaphore value in all zones. /dev/tzsync Uncommitted A device driver file to be used to mmap the semaphore memory. /usr/sbin/tzreload Committed man page tzreload(1M) Release ------- A patch binding is requested. Bug/RFEs ------- 6751272 RFE: Solaris timezone patches should not require reboot 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: on 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Fri Sep 25 10:37:00 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PHaxro012605 for ; Fri, 25 Sep 2009 10:37:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8PHatmi011961 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 26 Sep 2009 01:36:58 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00M01FLKHC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 11:36:56 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00HBVFLKU850@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 11:36:56 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8PHatwO005504 for ; Fri, 25 Sep 2009 10:36:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQJ00L00FJ3U500@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 10:36:55 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQJ00FPWFLHVVG0@fe-sfbay-10.sun.com>; Fri, 25 Sep 2009 10:36:54 -0700 (PDT) Date: Fri, 25 Sep 2009 10:36:53 -0700 From: "Garrett D'Amore" Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Suhasini Peddada Cc: PSARC-ext@sun.com, Nobutomo.Nakano@sun.com Message-id: <4ABCFFB5.5060401@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4236 +1. Failure to cache tz information if the service isn't available may have a negative performance impact, but since this isn't supposed to be the normal case, I suppose it is acceptable. - Garrett Suhasini Peddada wrote: > I am submitting the fasttrak for Nobutomo and seeking a patch binding. Time out is Oct 2nd, 2009. > > Thanks, > -Suha > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Timezone cache renewal > 1.2. Name of Document Author/Supplier: > Author: Nobutomo Nakano > 1.3 Date of This Document: > 25 September, 2009 > 4. Technical Description > > Name > ---- > Timezone cache renewal in ctime(3C) (aka No reboot on timezone update) > > Background > ---------- > Timezone patches contain the updates of the zoneinfo database files. > > Internally libc caches the timezone information and never rereads > it. This means that when the timezone patches are applied and updates > are made to the zoneinfo database, files they are not activated until > the system is rebooted or the various process that use the timezone > information are restarted. > > The impact of a reboot for the changes in the timezone is significant > especially for those customers with many Sun servers running many > domains. > > Customers have requested that when applying timezone patches, a > reboot is not required. To satisfy the requirement, the timezone > code could check if the zoneinfo database files have been updated > since the last time by issuing the stat(2) system call. However, as > stat() is an expensive system call, the addition of the stat() call > would result in a great performance regression in the timezone code > in libc. Therefore, a more efficient method that notifies libc that > the zoneinfo database has been updated needs to be introduced. > > Proposal > -------- > All the ctime(3C) and mktime(3C) functions will use a semaphore on > per zone shared memory pages. The semaphore can be attached to process > by using mmap(2) to a software driver. The software driver allows > mmap() to attach the shared memory page for semaphore, and also allows > a privileged ioctl (requires PRIV_PROC_OWNER) to modify the memory > contents(semaphore) for the zone. The software driver also allows to > modify the memory contents for all zones (additionally requires > PRIV_PROC_ZONE). The reason for using a software driver is solely to > protect the shared memory from being released, invalidated or corrupted. > > The ctime(3C) and mktime(3C) functions will test the semaphore before > using cache'd timezone information and, if it has changed, purge the > cache and re-read the zoneinfo file. No privilege is required to > test the semaphore. If the libc failed to open the device file, > ctime(3C) and mktime(3C) will not cache the timezone information. > > When zoneinfo database files are updated, a new utility tzreload(1M) > can be executed, by a privileged user, to propagate the change (update > the semaphore status on the shared memory). All subsequent calls to > ctime(3C) functions from any processes within the system will reread > the updated zoneinfo database file. tzreload command will be added to > the "Process Management" RBAC profile. > > Interfaces > ---------- > NAME STABILITY DESCRIPTION > ------------------------------------------------------------------- > TZSYNCIOC_INC Consolidation Private ioctl to increment > semaphore value. > TZSYNCIOC_INC_ALL_ZONES Consolidation Private ioctl to increment > semaphore value in all > zones. > /dev/tzsync Uncommitted A device driver file to be > used to mmap the semaphore > memory. > /usr/sbin/tzreload Committed man page tzreload(1M) > > Release > ------- > A patch binding is requested. > > Bug/RFEs > ------- > 6751272 RFE: Solaris timezone patches should not require reboot > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > on > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Nicolas.Williams@sun.com Fri Sep 25 11:16:33 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PIGWZp013708 for ; Fri, 25 Sep 2009 11:16:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8PIGOts006149; Sat, 26 Sep 2009 02:16:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00F0HHFHJ100@nwk-avmta-2.sfbay.sun.com>; Fri, 25 Sep 2009 11:16:29 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00AHAHFH6150@nwk-avmta-2.sfbay.sun.com>; Fri, 25 Sep 2009 11:16:29 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8PICnP9023786; Fri, 25 Sep 2009 13:12:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8PICneW023785; Fri, 25 Sep 2009 13:12:49 -0500 (CDT) Date: Fri, 25 Sep 2009 13:12:49 -0500 From: Nicolas Williams Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> To: Suhasini Peddada Cc: PSARC-ext@sun.com, Nobutomo.Nakano@sun.com Message-id: <20090925181248.GN1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 330 If the number of signals we have were not limited, I'd say it'd be better to use a signal for this as it seems likely to be faster to setup on exec than an mmap segment, it seems like a more generic scheme, and it seems simpler overall than adding a special driver. It'd sure be nice to have a VMS-like AST facility... Nico -- From Suhasini.Peddada@sun.com Fri Sep 25 11:36:19 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PIaJBW014314 for ; Fri, 25 Sep 2009 11:36:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8PIa2aH035458 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 25 Sep 2009 12:36:19 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ0050JICIE600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 12:36:18 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00HX2ICHUAB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 12:36:18 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8PIaCk9000408 for ; Fri, 25 Sep 2009 11:36:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQJ00L00HZBE900@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 11:36:16 -0700 (PDT) Received: from [129.145.154.60] ([unknown] [129.145.154.60]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQJ0038QICCHU00@fe-sfbay-09.sun.com>; Fri, 25 Sep 2009 11:36:16 -0700 (PDT) Date: Fri, 25 Sep 2009 11:36:12 -0700 From: Suhasini Peddada Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <20090925181248.GN1033@Sun.COM> Sender: Suhasini.Peddada@sun.com To: Nicolas Williams , Nobutomo.Nakano@sun.com Cc: Suhasini Peddada , PSARC-ext@sun.com Reply-to: Suhasini.Peddada@sun.com Message-id: <4ABD0D9C.605@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <20090925181248.GN1033@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 472 Hi Nobutomo, Can you please comment on Nico's questions given below? Thanks, -Suha On 09/25/09 11:12, Nicolas Williams wrote: > If the number of signals we have were not limited, I'd say it'd be > better to use a signal for this as it seems likely to be faster to setup > on exec than an mmap segment, it seems like a more generic scheme, and > it seems simpler overall than adding a special driver. > > It'd sure be nice to have a VMS-like AST facility... > > Nico From Nicolas.Williams@sun.com Fri Sep 25 11:40:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PIeQeR014369 for ; Fri, 25 Sep 2009 11:40:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PIeFZb019016; Fri, 25 Sep 2009 19:40:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00501IJ7U300@brm-avmta-1.central.sun.com>; Fri, 25 Sep 2009 12:40:19 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00HMHIJ7UAC0@brm-avmta-1.central.sun.com>; Fri, 25 Sep 2009 12:40:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8PIadeq023808; Fri, 25 Sep 2009 13:36:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8PIad7N023807; Fri, 25 Sep 2009 13:36:39 -0500 (CDT) Date: Fri, 25 Sep 2009 13:36:39 -0500 From: Nicolas Williams Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4ABD0D9C.605@sun.com> To: Suhasini Peddada Cc: Nobutomo.Nakano@sun.com, Suhasini Peddada , PSARC-ext@sun.com Message-id: <20090925183639.GO1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <20090925181248.GN1033@Sun.COM> <4ABD0D9C.605@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 184 On Fri, Sep 25, 2009 at 11:36:12AM -0700, Suhasini Peddada wrote: > Can you please comment on Nico's questions given below? No need really. My comment was more of a lament. Thanks. From Suhasini.Peddada@sun.com Fri Sep 25 11:49:42 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PInfHg015433 for ; Fri, 25 Sep 2009 11:49:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PIndYN024247 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 25 Sep 2009 19:49:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00H03IYRRS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 11:49:39 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00AE0IYR5V70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 11:49:39 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8PInc7m002019 for ; Fri, 25 Sep 2009 11:49:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQJ00L00IV8OL00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 11:49:38 -0700 (PDT) Received: from [129.145.154.60] ([unknown] [129.145.154.60]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQJ008GPIYOBRB0@fe-sfbay-10.sun.com>; Fri, 25 Sep 2009 11:49:38 -0700 (PDT) Date: Fri, 25 Sep 2009 11:49:36 -0700 From: Suhasini Peddada Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <20090925183639.GO1033@Sun.COM> Sender: Suhasini.Peddada@sun.com To: Nicolas Williams Cc: Nobutomo.Nakano@sun.com, Suhasini Peddada , PSARC-ext@sun.com Reply-to: Suhasini.Peddada@sun.com Message-id: <4ABD10C0.8050604@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <20090925181248.GN1033@Sun.COM> <4ABD0D9C.605@sun.com> <20090925183639.GO1033@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 265 Hi Nico, On 09/25/09 11:36, Nicolas Williams wrote: > On Fri, Sep 25, 2009 at 11:36:12AM -0700, Suhasini Peddada wrote: >> Can you please comment on Nico's questions given below? > > No need really. My comment was more of a lament. > O.k. Thanks. :-) -Suha From casper@holland.sun.com Sat Sep 26 04:25:12 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8QBPC6u018108 for ; Sat, 26 Sep 2009 04:25:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8QBP5vV011686 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Sat, 26 Sep 2009 12:25:11 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQK00101T1XVA00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 26 Sep 2009 05:25:09 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQK00I49T1WDL40@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 26 Sep 2009 05:25:08 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8QBP4Fm045735; Sat, 26 Sep 2009 12:25:04 +0100 (BST) Date: Sat, 26 Sep 2009 13:25:04 +0200 From: Casper.Dik@sun.com Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> Sender: casper@holland.sun.com To: Suhasini Peddada Cc: PSARC-ext@sun.com, Nobutomo.Nakano@sun.com Message-id: <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> Status: RO Content-Length: 1515 >Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >This information is Copyright 2009 Sun Microsystems >1. Introduction > 1.1. Project/Component Working Name: > Timezone cache renewal > 1.2. Name of Document Author/Supplier: > Author: Nobutomo Nakano > 1.3 Date of This Document: > 25 September, 2009 >4. Technical Description > >Name >---- >Timezone cache renewal in ctime(3C) (aka No reboot on timezone update) > >Background >---------- >Timezone patches contain the updates of the zoneinfo database files. > >Internally libc caches the timezone information and never rereads >it. This means that when the timezone patches are applied and updates >are made to the zoneinfo database, files they are not activated until >the system is rebooted or the various process that use the timezone >information are restarted. > >The impact of a reboot for the changes in the timezone is significant >especially for those customers with many Sun servers running many >domains. > Now that we have this large mechanism to update the timezone information, I'm missing a number of things: it appears not to be possible to change the timezone dynamically; there are customers who want this. In the initial implementation of Olson's code uses a link called "localtime" and with a broadcast mechanism we could have this function pretty much for free; should this not be added to this project? how is the semaphore checked and why is a mmap file in, say, /var/run not good for this purpose? Casper From ro@techfak.uni-bielefeld.de Mon Sep 28 04:52:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SBqWrQ015347 for ; Mon, 28 Sep 2009 04:52:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SBqPxW018244; Mon, 28 Sep 2009 12:52:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO00607JNF2M00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 04:52:27 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00HNYJNE7R80@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 04:52:27 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8SBlbJ3005243; Mon, 28 Sep 2009 11:52:26 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-2214053; Mon, 28 Sep 2009 11:52:25 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-31110552; Mon, 28 Sep 2009 11:52:24 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-20056104; Mon, 28 Sep 2009 11:52:24 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 7E79D99; Mon, 28 Sep 2009 13:52:23 +0200 (CEST) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n8SBqNM06816; Mon, 28 Sep 2009 13:52:23 +0200 (MEST) Date: Mon, 28 Sep 2009 13:52:21 +0200 From: Rainer Orth Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: Suhasini Peddada's message of "Fri, 25 Sep 2009 10:14:21 -0700 (PDT)" Sender: ro@techfak.uni-bielefeld.de To: Suhasini Peddada Cc: PSARC-ext@sun.com, Nobutomo.Nakano@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.925sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 23 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> Status: RO Content-Length: 855 Suhasini Peddada writes: > Interfaces > ---------- > NAME STABILITY DESCRIPTION > ------------------------------------------------------------------- > TZSYNCIOC_INC Consolidation Private ioctl to increment > semaphore value. > TZSYNCIOC_INC_ALL_ZONES Consolidation Private ioctl to increment > semaphore value in all > zones. > /dev/tzsync Uncommitted A device driver file to be > used to mmap the semaphore What use is it to have the device name be Uncommitted if both ioctls are Consolidation Private. This seems like an implementation detail to me and would better be Consolidation Private as well. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Suhasini.Peddada@sun.com Mon Sep 28 09:07:30 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SG7UcT019823 for ; Mon, 28 Sep 2009 09:07:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SG7TZl012124 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Sep 2009 09:07:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO0000DVGHGN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 09:07:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00LS6VGH0D40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 09:07:29 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8SG7Tg9002143 for ; Mon, 28 Sep 2009 09:07:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQO00000V4Y4I00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 09:07:29 -0700 (PDT) Received: from [129.145.154.60] ([unknown] [129.145.154.60]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQO000FLVGDMW30@fe-sfbay-10.sun.com>; Mon, 28 Sep 2009 09:07:28 -0700 (PDT) Date: Mon, 28 Sep 2009 09:07:25 -0700 From: Suhasini Peddada Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> Sender: Suhasini.Peddada@sun.com To: casper.dik@sun.com, Nobutomo.Nakano@sun.com Cc: Suhasini Peddada , PSARC-ext@sun.com Reply-to: Suhasini.Peddada@sun.com Message-id: <4AC0DF3D.3090202@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 1737 Hi Nobutomo, Please clarify the questions by Casper in the included e-mail. Thanks, -Suha On 09/26/09 04:25, Casper.Dik@Sun.COM wrote: > >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Timezone cache renewal >> 1.2. Name of Document Author/Supplier: >> Author: Nobutomo Nakano >> 1.3 Date of This Document: >> 25 September, 2009 >> 4. Technical Description >> >> Name >> ---- >> Timezone cache renewal in ctime(3C) (aka No reboot on timezone update) >> >> Background >> ---------- >> Timezone patches contain the updates of the zoneinfo database files. >> >> Internally libc caches the timezone information and never rereads >> it. This means that when the timezone patches are applied and updates >> are made to the zoneinfo database, files they are not activated until >> the system is rebooted or the various process that use the timezone >> information are restarted. >> >> The impact of a reboot for the changes in the timezone is significant >> especially for those customers with many Sun servers running many >> domains. >> > > Now that we have this large mechanism to update the timezone information, > I'm missing a number of things: > > it appears not to be possible to change the timezone dynamically; > there are customers who want this. In the initial implementation > of Olson's code uses a link called "localtime" and with a broadcast > mechanism we could have this function pretty much for free; > should this not be added to this project? > > how is the semaphore checked and why is a mmap file in, say, > /var/run not good for this purpose? > > > Casper > From Suhasini.Peddada@sun.com Mon Sep 28 09:10:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SGAlFG019905 for ; Mon, 28 Sep 2009 09:10:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SGAgwH004159 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Sep 2009 17:10:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO00F0ZVLXIE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 09:10:45 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00F5RVLWZSD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 09:10:44 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8SGAi57016070 for ; Mon, 28 Sep 2009 09:10:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQO00K00VCGAV00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 09:10:44 -0700 (PDT) Received: from [129.145.154.60] ([unknown] [129.145.154.60]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQO006QZVLTNO80@fe-sfbay-09.sun.com>; Mon, 28 Sep 2009 09:10:43 -0700 (PDT) Date: Mon, 28 Sep 2009 09:10:41 -0700 From: Suhasini Peddada Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: Sender: Suhasini.Peddada@sun.com To: Rainer Orth , Nobutomo.Nakano@sun.com Cc: Suhasini Peddada , PSARC-ext@sun.com Reply-to: Suhasini.Peddada@sun.com Message-id: <4AC0E001.8030801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 894 Hi Nobutomo, Please provide the clarifications to questions from Rainer in the included e-mail. Thanks, -Suha On 09/28/09 04:52, Rainer Orth wrote: > Suhasini Peddada writes: > >> Interfaces >> ---------- >> NAME STABILITY DESCRIPTION >> ------------------------------------------------------------------- >> TZSYNCIOC_INC Consolidation Private ioctl to increment >> semaphore value. >> TZSYNCIOC_INC_ALL_ZONES Consolidation Private ioctl to increment >> semaphore value in all >> zones. >> /dev/tzsync Uncommitted A device driver file to be >> used to mmap the semaphore > > What use is it to have the device name be Uncommitted if both ioctls are > Consolidation Private. This seems like an implementation detail to me and > would better be Consolidation Private as well. > > Rainer > From Darren.Moffat@sun.com Mon Sep 28 09:28:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SGSTQ5020444 for ; Mon, 28 Sep 2009 09:28:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SGSSLa015924 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Sep 2009 09:28:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO0020DWFG6M00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 09:28:28 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00LVQWFF0E50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 09:28:28 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8SGSRbi013964 for ; Mon, 28 Sep 2009 16:28:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQO00K00W678400@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 17:28:10 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQO00AVPWEXJM40@fe-emea-09.sun.com>; Mon, 28 Sep 2009 17:28:10 +0100 (BST) Date: Mon, 28 Sep 2009 17:28:09 +0100 From: Darren J Moffat Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC0DF3D.3090202@sun.com> Sender: Darren.Moffat@sun.com To: Suhasini.Peddada@sun.com Cc: Casper.Dik@sun.com, Nobutomo.Nakano@sun.com, Suhasini Peddada , PSARC-ext@sun.com Message-id: <4AC0E419.7070007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0DF3D.3090202@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 865 Why isn't the implementation of this using the port_associate(3C) facility to watch for the default timezone file being updated ? Using port_associate(3C) means it is possible to update per process without requiring the admin to run a (privileged) command. I really don't like the idea of the requirement of the privileged command. Is this because it has patch binding and port_associate(3C) isn't available in all releases this is intended to be patched to ? If so I would like to see that tzreload is "Obsolete Committed" and the OpenSolaris/ONNV release of this use port_associate(3C) instead of the method proposed. The case says ctime(3C). Isn't it really calling of localtime_r(3C),tzset(3C) and mktime(3C) that causes the update to the cached TZ ?, ie those functions in libc that call the static getsystemTZ() function. -- Darren J Moffat From Nicolas.Williams@sun.com Mon Sep 28 09:48:51 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SGmoOm020917 for ; Mon, 28 Sep 2009 09:48:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SGml9C023178; Mon, 28 Sep 2009 09:48:47 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO0030LXDBEG00@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Sep 2009 09:48:47 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00L0PXDB0DA0@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Sep 2009 09:48:47 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8SGj5MO025688; Mon, 28 Sep 2009 11:45:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8SGj5mI025687; Mon, 28 Sep 2009 11:45:05 -0500 (CDT) Date: Mon, 28 Sep 2009 11:45:05 -0500 From: Nicolas Williams Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC0E419.7070007@Sun.COM> To: Darren J Moffat Cc: Suhasini.Peddada@sun.com, Casper.Dik@sun.com, Nobutomo.Nakano@sun.com, Suhasini Peddada , PSARC-ext@sun.com Message-id: <20090928164504.GX1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0DF3D.3090202@sun.com> <4AC0E419.7070007@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 411 On Mon, Sep 28, 2009 at 05:28:09PM +0100, Darren J Moffat wrote: > Why isn't the implementation of this using the port_associate(3C) > facility to watch for the default timezone file being updated ? [Not the i-team] Probably because that would mean having a thread to wait in port_get(3C). That seems too heavyweight to me. I'd love to see something asynchronous, like a signal or "AST" for this. Nico -- From casper@holland.sun.com Mon Sep 28 10:05:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SH5LAB021754 for ; Mon, 28 Sep 2009 10:05:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8SH5Jni011419 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 29 Sep 2009 01:05:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO0040HY4VDD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:05:19 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00L7AY4U0880@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:05:18 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SH5CAq025933; Mon, 28 Sep 2009 18:05:12 +0100 (BST) Date: Mon, 28 Sep 2009 19:05:12 +0200 From: Casper.Dik@sun.com Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <20090928164504.GX1033@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Darren J Moffat , Suhasini.Peddada@sun.com, Nobutomo.Nakano@sun.com, Suhasini Peddada , PSARC-ext@sun.com Message-id: <200909281705.n8SH5CAq025933@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0DF3D.3090202@sun.com> <4AC0E419.7070007@Sun.COM> <20090928164504.GX1033@Sun.COM> Status: RO Content-Length: 666 >On Mon, Sep 28, 2009 at 05:28:09PM +0100, Darren J Moffat wrote: >> Why isn't the implementation of this using the port_associate(3C) >> facility to watch for the default timezone file being updated ? > >[Not the i-team] Probably because that would mean having a thread to >wait in port_get(3C). That seems too heavyweight to me. I'd love to >see something asynchronous, like a signal or "AST" for this. Or perhaps because that mechanism requires an open file descriptor *and* it requires to poll the port or add a thread. And fds cached in library routines have issues with being "closed" by programs. (An mmap'ed object would not have that issue) Casper From gdamore@sun.com Mon Sep 28 10:12:34 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SHCXTh021828 for ; Mon, 28 Sep 2009 10:12:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SHCWOU014774 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Sep 2009 10:12:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO00401YGWQ400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:12:32 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00LZEYGV0C90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:12:31 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8SHCVML023534 for ; Mon, 28 Sep 2009 10:12:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQO00L00XNTGX00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:12:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQO00LLAYGL9900@fe-sfbay-09.sun.com>; Mon, 28 Sep 2009 10:12:22 -0700 (PDT) Date: Mon, 28 Sep 2009 10:12:21 -0700 From: "Garrett D'Amore" Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <20090928164504.GX1033@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Darren J Moffat , Suhasini.Peddada@sun.com, Casper.Dik@sun.com, Nobutomo.Nakano@sun.com, Suhasini Peddada , PSARC-ext@sun.com Message-id: <4AC0EE75.4070800@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0DF3D.3090202@sun.com> <4AC0E419.7070007@Sun.COM> <20090928164504.GX1033@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 858 Nicolas Williams wrote: > On Mon, Sep 28, 2009 at 05:28:09PM +0100, Darren J Moffat wrote: > >> Why isn't the implementation of this using the port_associate(3C) >> facility to watch for the default timezone file being updated ? >> > > [Not the i-team] Probably because that would mean having a thread to > wait in port_get(3C). That seems too heavyweight to me. I'd love to > see something asynchronous, like a signal or "AST" for this. > > Nico > Yes, having an extra thread in every process seems ... too heavyweight. To be honest, when I reviewed this, I didn't even think of port_get() or port_associate. I think part of this is a problem stemming from lack of knowledge about new facilities. Its hard for project teams to stay on top of every new feature that is introduced, and this might be one of those cases. -- Garrett From nobutomo.nakano@sun.com Mon Sep 28 10:16:01 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SHG0SJ021903 for ; Mon, 28 Sep 2009 10:16:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8SHFvOo030846; Mon, 28 Sep 2009 11:15:59 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO0060DYMN3H00@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 11:15:59 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00M5RYMM9I50@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 11:15:58 -0600 (MDT) Received: from [129.146.56.122] (akashi.SFBay.Sun.COM [129.146.56.122]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8SHFwOX607751; Mon, 28 Sep 2009 10:15:58 -0700 (PDT) Date: Mon, 28 Sep 2009 10:15:58 -0700 From: Nobutomo Nakano Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <4AC0EF4E.8050007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 1167 Casper.Dik@Sun.COM wrote: > Now that we have this large mechanism to update the timezone information, > I'm missing a number of things: > > it appears not to be possible to change the timezone dynamically; > there are customers who want this. In the initial implementation > of Olson's code uses a link called "localtime" and with a broadcast > mechanism we could have this function pretty much for free; > should this not be added to this project? It is possible if timezone is not supplied by TZ env variable. localtime() will reload /etc/default/init as well. If timezone is supplied by TZ env variable, "localtime" approach is needed. Currently "localtime" isn't read by default, but it is out of scope of this project. Using Olson's code can change the timezone dynamically, but only for processes which were restarted or started after the file is changed. Active processes which have loaded "localtime" never reloads the file. > how is the semaphore checked and why is a mmap file in, say, > /var/run not good for this purpose? If the file can be truncated, it could potentially send SIGSEGV to all active processes that calls ctime(3C). -Nakano From nobutomo.nakano@sun.com Mon Sep 28 10:29:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SHTnqr022066 for ; Mon, 28 Sep 2009 10:29:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8SHTgae037842; Mon, 28 Sep 2009 11:29:48 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQO0071TZ9NF600@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 11:29:47 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQO00M4DZ9K9P50@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 11:29:45 -0600 (MDT) Received: from [129.146.56.122] (akashi.SFBay.Sun.COM [129.146.56.122]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8SHTiKp609783; Mon, 28 Sep 2009 10:29:44 -0700 (PDT) Date: Mon, 28 Sep 2009 10:29:44 -0700 From: Nobutomo Nakano Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC0E419.7070007@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4AC0F288.2010804@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0DF3D.3090202@sun.com> <4AC0E419.7070007@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 1154 Darren J Moffat wrote: > Why isn't the implementation of this using the port_associate(3C) > facility to watch for the default timezone file being updated ? localtime(3C) is very performance sensitive. We don't want to make any extra system calls or threads interactions from the function. > Using port_associate(3C) means it is possible to update per process > without requiring the admin to run a (privileged) command. I really > don't like the idea of the requirement of the privileged command. Is > this because it has patch binding and port_associate(3C) isn't available > in all releases this is intended to be patched to ? If so I would like > to see that tzreload is "Obsolete Committed" and the OpenSolaris/ONNV > release of this use port_associate(3C) instead of the method proposed. > > The case says ctime(3C). Isn't it really calling of > localtime_r(3C),tzset(3C) and mktime(3C) that causes the update to the > cached TZ ?, ie those functions in libc that call the static > getsystemTZ() function. All functions listed in the ctime(3C) except for gmtime* and asctime* will update the cached timezone information. -Nakano From casper@holland.sun.com Mon Sep 28 10:56:51 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SHuoWS023253 for ; Mon, 28 Sep 2009 10:56:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SHua3U017591 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Mon, 28 Sep 2009 18:56:49 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP007050INGX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:56:47 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP0073G0IMCS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 10:56:47 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SHui9P038393; Mon, 28 Sep 2009 18:56:44 +0100 (BST) Date: Mon, 28 Sep 2009 19:56:44 +0200 From: Casper.Dik@sun.com Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC0EF4E.8050007@Sun.COM> Sender: casper@holland.sun.com To: Nobutomo Nakano Cc: PSARC-ext@sun.com Message-id: <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> Status: RO Content-Length: 1610 >Casper.Dik@Sun.COM wrote: >> Now that we have this large mechanism to update the timezone information, >> I'm missing a number of things: >> >> it appears not to be possible to change the timezone dynamically; >> there are customers who want this. In the initial implementation >> of Olson's code uses a link called "localtime" and with a broadcast >> mechanism we could have this function pretty much for free; >> should this not be added to this project? > >It is possible if timezone is not supplied by TZ env variable. >localtime() will reload /etc/default/init as well. If timezone is >supplied by TZ env variable, "localtime" approach is needed. >Currently "localtime" isn't read by default, but it is out of >scope of this project. Except that localtime *may* read /etc/default/init but by default it will NOT because all processes have $TZ set from the boot time /etc/default/init. You can get that in two ways: use "localtime" or not set $TZ for all processes; as setting $TZ is a optimization. So perhaps that's a better solution: do not set $TZ in the environment. >Using Olson's code can change the timezone dynamically, but only >for processes which were restarted or started after the file is >changed. Active processes which have loaded "localtime" never >reloads the file. > >> how is the semaphore checked and why is a mmap file in, say, >> /var/run not good for this purpose? > >If the file can be truncated, it could potentially send SIGSEGV to >all active processes that calls ctime(3C). By root, right? Root can also truncate /lib/libc.so.1 so that doesn't fly. Casper From casper@holland.sun.com Mon Sep 28 11:35:26 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SIZPkU024952 for ; Mon, 28 Sep 2009 11:35:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SIZPNl028705 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Mon, 28 Sep 2009 11:35:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00A012AZ3Z00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 11:35:23 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP007D62AYCW30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 11:35:22 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SIZJaN045567; Mon, 28 Sep 2009 19:35:19 +0100 (BST) Date: Mon, 28 Sep 2009 20:35:19 +0200 From: Casper.Dik@sun.com Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC0EF4E.8050007@Sun.COM> Sender: casper@holland.sun.com To: Nobutomo Nakano Cc: PSARC-ext@sun.com Message-id: <200909281835.n8SIZJaN045567@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> Status: RO Content-Length: 430 >> how is the semaphore checked and why is a mmap file in, say, >> /var/run not good for this purpose? > >If the file can be truncated, it could potentially send SIGSEGV to >all active processes that calls ctime(3C). > Abort from that I don't properly think we need to code truncated root owned files, like libc, there are some outs: - non-faulting loads (only for SPARC??) - mincore(address, pagesize(), &bit) Casper From nobutomo.nakano@sun.com Mon Sep 28 12:16:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SJGcJS027063 for ; Mon, 28 Sep 2009 12:16:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8SJGVXP023696; Tue, 29 Sep 2009 03:16:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00I0347MBT00@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 13:16:34 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP00MYB47L9RC0@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 13:16:33 -0600 (MDT) Received: from [129.146.56.122] (akashi.SFBay.Sun.COM [129.146.56.122]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8SJGXrj631303; Mon, 28 Sep 2009 12:16:33 -0700 (PDT) Date: Mon, 28 Sep 2009 12:16:33 -0700 From: Nobutomo Nakano Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <4AC10B91.9090400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 1994 Casper.Dik@Sun.COM wrote: >> Casper.Dik@Sun.COM wrote: >>> Now that we have this large mechanism to update the timezone information, >>> I'm missing a number of things: >>> >>> it appears not to be possible to change the timezone dynamically; >>> there are customers who want this. In the initial implementation >>> of Olson's code uses a link called "localtime" and with a broadcast >>> mechanism we could have this function pretty much for free; >>> should this not be added to this project? >> It is possible if timezone is not supplied by TZ env variable. >> localtime() will reload /etc/default/init as well. If timezone is >> supplied by TZ env variable, "localtime" approach is needed. >> Currently "localtime" isn't read by default, but it is out of >> scope of this project. > > Except that localtime *may* read /etc/default/init but by default it > will NOT because all processes have $TZ set from the boot time > /etc/default/init. > > You can get that in two ways: use "localtime" or not set $TZ for > all processes; as setting $TZ is a optimization. You can still use "TZ=localtime" and make a "localtime" link under the zoneinfo dir, but I agree that reading "localtime" by default would be nice to have for those people who would like to change the timezone dynamically. >>> how is the semaphore checked and why is a mmap file in, say, >>> /var/run not good for this purpose? >> If the file can be truncated, it could potentially send SIGSEGV to >> all active processes that calls ctime(3C). > > By root, right? Root can also truncate /lib/libc.so.1 so that doesn't fly. Yes. But libc.so.1 would be an extreme example. We thought that such file/memory page needs to be protected in certain degree to avoid catastrophic result. If that's a regular file someone(has root privilege) may carelessly truncate it or unlink and re-create it. We just wanted to minimize those risks. If we shouldn't worry about those, I'll revise the spec to use a regular file. -Nakano From Nicolas.Williams@sun.com Mon Sep 28 12:21:13 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SJLDJE027194 for ; Mon, 28 Sep 2009 12:21:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SJLAfM013995; Mon, 28 Sep 2009 12:21:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00G194FAN700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 12:21:10 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP00DK94F9MKC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 12:21:09 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8SJHSSl025832; Mon, 28 Sep 2009 14:17:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8SJHShW025831; Mon, 28 Sep 2009 14:17:28 -0500 (CDT) Date: Mon, 28 Sep 2009 14:17:28 -0500 From: Nicolas Williams Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC0F288.2010804@Sun.COM> To: Nobutomo Nakano Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <20090928191728.GD1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0DF3D.3090202@sun.com> <4AC0E419.7070007@Sun.COM> <4AC0F288.2010804@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 771 On Mon, Sep 28, 2009 at 10:29:44AM -0700, Nobutomo Nakano wrote: > Darren J Moffat wrote: > >Why isn't the implementation of this using the port_associate(3C) > >facility to watch for the default timezone file being updated ? > > localtime(3C) is very performance sensitive. We don't want to > make any extra system calls or threads interactions from the > function. Darren's scheme wouldn't require anything more than adding a membar in ctime() and friends in the common case. The problem with Darren's proposal is that it's too invasive (extra thread, extra file descriptors, as Casper points out, though the library could recover from closefrom(3C) clobbering its file descriptor(s)). But performance is not a problem for Darren's proposed alternative. Nico -- From Nicolas.Williams@sun.com Mon Sep 28 12:23:03 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SJN2tY027358 for ; Mon, 28 Sep 2009 12:23:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SJMg8e014988; Mon, 28 Sep 2009 20:23:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00D094IA9M00@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Sep 2009 12:22:58 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP007RF4I9CR70@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Sep 2009 12:22:57 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8SJJGrU025838; Mon, 28 Sep 2009 14:19:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8SJJG00025837; Mon, 28 Sep 2009 14:19:16 -0500 (CDT) Date: Mon, 28 Sep 2009 14:19:16 -0500 From: Nicolas Williams Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC10B91.9090400@Sun.COM> To: Nobutomo Nakano Cc: Casper.Dik@sun.com, PSARC-ext@sun.com Message-id: <20090928191916.GE1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> <4AC10B91.9090400@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 966 On Mon, Sep 28, 2009 at 12:16:33PM -0700, Nobutomo Nakano wrote: > Casper.Dik@Sun.COM wrote: > >>It is possible if timezone is not supplied by TZ env variable. > >>localtime() will reload /etc/default/init as well. If timezone is > >>supplied by TZ env variable, "localtime" approach is needed. > >>Currently "localtime" isn't read by default, but it is out of > >>scope of this project. > > > >Except that localtime *may* read /etc/default/init but by default it > >will NOT because all processes have $TZ set from the boot time > >/etc/default/init. > > > >You can get that in two ways: use "localtime" or not set $TZ for > >all processes; as setting $TZ is a optimization. > > You can still use "TZ=localtime" and make a "localtime" link > under the zoneinfo dir, but I agree that reading "localtime" > by default would be nice to have for those people who would > like to change the timezone dynamically. The CPG project (PSARC/2009/271) would help with that. From casper@holland.sun.com Mon Sep 28 12:25:06 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SJP5oR027471 for ; Mon, 28 Sep 2009 12:25:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SJOxTt016349 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Mon, 28 Sep 2009 20:25:04 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00H034LQ4Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 12:25:02 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP00DGP4LPMKE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 28 Sep 2009 12:25:02 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SJOxQb058133; Mon, 28 Sep 2009 20:24:59 +0100 (BST) Date: Mon, 28 Sep 2009 21:24:59 +0200 From: Casper.Dik@sun.com Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC10B91.9090400@Sun.COM> Sender: casper@holland.sun.com To: Nobutomo Nakano Cc: PSARC-ext@sun.com Message-id: <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> <4AC10B91.9090400@Sun.COM> Status: RO Content-Length: 1534 >You can still use "TZ=localtime" and make a "localtime" link >under the zoneinfo dir, but I agree that reading "localtime" >by default would be nice to have for those people who would >like to change the timezone dynamically. It would be nice if "localtime" pointed to a fixed location and that that fixed location (e.g., /var/init/localtime) and make that function point to somewhere in /usr/share/lib/zoneinfo so that /usr remain mostly read-only. >>>> how is the semaphore checked and why is a mmap file in, say, >>>> /var/run not good for this purpose? >>> If the file can be truncated, it could potentially send SIGSEGV to >>> all active processes that calls ctime(3C). >> >> By root, right? Root can also truncate /lib/libc.so.1 so that doesn't fly. > >Yes. But libc.so.1 would be an extreme example. We thought >that such file/memory page needs to be protected in certain >degree to avoid catastrophic result. If that's a regular file >someone(has root privilege) may carelessly truncate it or unlink >and re-create it. We just wanted to minimize those risks. If >we shouldn't worry about those, I'll revise the spec to use >a regular file. I wouldn't see how that could happen other then, say, truncating /bin/cat. You could measure how expensive mincore() is (it's seems about 0.5-1.0us per call which is possibly a bit too much for each time call) but I think it is not needed. Of course, if other folks think that the original proposal is a proper "heavy weight" mechanism, please let them speak up. Casper From nobutomo.nakano@sun.com Wed Sep 30 09:59:03 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8UGx2Yu021878 for ; Wed, 30 Sep 2009 09:59:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8UGwwrM011438; Thu, 1 Oct 2009 00:58:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQS00M0ZN6AJC00@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 09:58:58 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQS00ISSN69PY40@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 09:58:57 -0700 (PDT) Received: from [129.146.56.122] (akashi.SFBay.Sun.COM [129.146.56.122]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8UGwudr139022; Wed, 30 Sep 2009 09:58:57 -0700 (PDT) Date: Wed, 30 Sep 2009 09:58:57 -0700 From: Nobutomo Nakano Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <4AC38E51.3060305@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_vw5DzXJK4hDtjuhy3Lj2vg)" X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> <4AC10B91.9090400@Sun.COM> <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 3226 This is a multi-part message in MIME format. --Boundary_(ID_vw5DzXJK4hDtjuhy3Lj2vg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Casper.Dik@Sun.COM wrote: > Of course, if other folks think that the original proposal is a proper > "heavy weight" mechanism, please let them speak up. > attached new spec. It will no longer use the software driver, but will use a regular file under /var/run. -Nakano --Boundary_(ID_vw5DzXJK4hDtjuhy3Lj2vg) Content-type: text/plain; name=fast_track-new3.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=fast_track-new3.txt Name ---- Timezone cache renewal in ctime(3C) (aka No reboot on timezone update) Background ---------- Timezone patches contain the updates of the zoneinfo database files. Internally libc caches the timezone information and never rereads it. This means that when the timezone patches are applied and updates are made to the zoneinfo database, files are not activated until the system is rebooted or the various process that use the timezone information are restarted. The impact of a reboot for the changes in the timezone is significant especially for those customers with many Sun servers running many domains. Customers have requested that when applying timezone patches, a reboot is not required. To satisfy the requirement, the timezone code could check if the zoneinfo database files have been updated since the last time by issuing the stat(2) system call. However, as stat() is an expensive system call, the addition of the stat() call would result in a great performance regression in the timezone code in libc. Therefore, a more efficient method that notifies libc that the zoneinfo database has been updated needs to be introduced. Proposal -------- All the ctime(3C) and mktime(3C) functions will use a semaphore on per zone shared file. ctime(3C) and mktime(3C) use the semaphore by attaching the file using mmap(2). The semaphore file is a regular file and owned by root and has permission 0644. It is created right after /var/run is mounted. The ctime(3C) and mktime(3C) functions will test the semaphore before using cache'd timezone information, and if it has changed, purge the cache and re-read the zoneinfo file. If the libc failed to open the semaphore file, ctime(3C) and mktime(3C) will not cache the timezone information. When zoneinfo database files are updated, a new utility tzreload(1M) can be executed, by a privileged user, to propagate the change (update the semaphore status). All subsequent calls to ctime(3C) functions from any processes within the system will reread the updated zoneinfo database file. tzreload command will be added to the "Process Management" RBAC profile. Interfaces ---------- NAME STABILITY DESCRIPTION ------------------------------------------------------------------- /var/run/tzsync Uncommitted A regular file to be used to mmap the semaphore /usr/sbin/tzreload Committed man page tzreload(1M) Release ------- A patch binding is requested. Bug/RFEs ------- 6751272 RFE: Solaris timezone patches should not require reboot --Boundary_(ID_vw5DzXJK4hDtjuhy3Lj2vg)-- From nobutomo.nakano@sun.com Tue Oct 6 12:59:40 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n96Jxe71022960 for ; Tue, 6 Oct 2009 12:59:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n96JxdFN012575 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 6 Oct 2009 12:59:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR300105ZJFC400@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 06 Oct 2009 13:59:39 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR300LCDZJEIX20@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 06 Oct 2009 13:59:39 -0600 (MDT) Received: from [129.146.56.122] (akashi.SFBay.Sun.COM [129.146.56.122]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n96JxcUR301763 for ; Tue, 06 Oct 2009 12:59:38 -0700 (PDT) Date: Tue, 06 Oct 2009 12:59:38 -0700 From: Nobutomo Nakano Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC38E51.3060305@Sun.COM> To: PSARC-ext@sun.com Message-id: <4ACBA1AA.4010809@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9Y0qzLxGp2BfxzCvcGsJgg)" X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> <4AC10B91.9090400@Sun.COM> <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> <4AC38E51.3060305@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 2828 This is a multi-part message in MIME format. --Boundary_(ID_9Y0qzLxGp2BfxzCvcGsJgg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT putting Casper's response for the record. I'd believe that all the questions have been clarified and there are no more pending issues. Thanks! -Nakano Nobutomo Nakano wrote: > Casper.Dik@Sun.COM wrote: >> Of course, if other folks think that the original proposal is a proper >> "heavy weight" mechanism, please let them speak up. >> > > attached new spec. It will no longer use the software driver, > but will use a regular file under /var/run. > > -Nakano > --Boundary_(ID_9Y0qzLxGp2BfxzCvcGsJgg) Content-type: message/rfc822; name="Attached Message" Content-disposition: inline; filename="Attached Message" Return-path: Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9178Iti301138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 01 Oct 2009 00:08:19 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9178HQW052259; Thu, 01 Oct 2009 08:08:17 +0100 (BST) Date: Thu, 01 Oct 2009 09:08:17 +0200 From: Casper.Dik@Sun.COM Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <4AC38CB0.1050407@Sun.COM> Sender: casper@holland.sun.com To: Nobutomo Nakano Cc: Suhasini.Peddada@Sun.COM Message-id: <200910010708.n9178HQW052259@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> <4AC10B91.9090400@Sun.COM> <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> <4AC1303F.8060808@Sun.COM> <200909290718.n8T7Iv4F003392@dm-holland-02.uk.sun.com> <4AC2395A.1090802@Sun.COM> <4AC38CB0.1050407@Sun.COM> >Hi Casper, > >I just wanted to check with you if my response answered your >question. Please let me know so that we can proceed with >the new spec. Sounds fine; make sure that when you create the file that it is created atomically: i.e., make a temporary file in /var/run make it getpagesize() big then rename it into the tzload file I would implement that in the tzreload command (and make sure you can only run that once) Also make sure that all commands which start before /var/run is mounted always try to open the file until it exists. Casper --Boundary_(ID_9Y0qzLxGp2BfxzCvcGsJgg)-- From gdamore@Sun.COM Wed Oct 7 08:34:33 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n97FYWYE001133 for ; Wed, 7 Oct 2009 08:34:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n97FYRLq001465 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Oct 2009 23:34:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR500D0ZHXEPH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Oct 2009 08:34:26 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR500DAUHXE7710@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Oct 2009 08:34:26 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n97FYQDY005400 for ; Wed, 07 Oct 2009 08:34:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR500E00HEMS400@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 07 Oct 2009 08:34:26 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR500JZWHX7T490@fe-sfbay-09.sun.com>; Wed, 07 Oct 2009 08:34:20 -0700 (PDT) Date: Wed, 07 Oct 2009 08:34:19 -0700 From: "Garrett D'Amore" Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@Sun.COM To: Casper.Dik@Sun.COM Cc: Nobutomo Nakano , PSARC-ext@Sun.COM Message-id: <4ACCB4FB.9090409@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> <200909261125.n8QBP4Fm045735@dm-holland-02.uk.sun.com> <4AC0EF4E.8050007@Sun.COM> <200909281756.n8SHui9P038393@dm-holland-02.uk.sun.com> <4AC10B91.9090400@Sun.COM> <200909281924.n8SJOxQb058133@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 82 With the latest materials updates, the case looks good to me. +1 - Garrett From Suhasini.Peddada@sun.com Wed Oct 7 10:42:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n97HgQAk005723 for ; Wed, 7 Oct 2009 10:42:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n97HgPri064049 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Oct 2009 11:42:25 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR500A03NUN6V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Oct 2009 10:42:24 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR5007EONUNAWC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Oct 2009 10:42:23 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n97HgNK3022061 for ; Wed, 07 Oct 2009 10:42:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR500100KV86V00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Oct 2009 10:42:23 -0700 (PDT) Received: from [129.145.154.60] ([unknown] [129.145.154.60]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR500LKTNU6PV90@fe-sfbay-09.sun.com>; Wed, 07 Oct 2009 10:42:09 -0700 (PDT) Date: Wed, 07 Oct 2009 10:42:06 -0700 From: Suhasini Peddada Subject: Re: Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009] In-reply-to: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> Sender: Suhasini.Peddada@sun.com To: PSARC-ext@sun.com Cc: Nobutomo.Nakano@sun.com Reply-to: Suhasini.Peddada@sun.com Message-id: <4ACCD2EE.9060604@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909251714.n8PHELm8011990@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 69 This case was approved during today's PSARC meeting. Thanks, -Suha