From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 20:49:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20BCED81; Tue, 11 Nov 2014 20:49:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE125AEA; Tue, 11 Nov 2014 20:49:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D731EB999; Tue, 11 Nov 2014 15:49:26 -0500 (EST) From: John Baldwin To: Charles Swiger Subject: Re: Changing timezone without reboot/restarting each service? Date: Tue, 11 Nov 2014 15:47:37 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <5460B143.6080206@FreeBSD.org> <201411111357.40061.jhb@freebsd.org> <5330A42B-CBCA-4349-BE12-777401272050@mac.com> In-Reply-To: <5330A42B-CBCA-4349-BE12-777401272050@mac.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411111547.38001.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Nov 2014 15:49:26 -0500 (EST) Cc: freebsd-current@freebsd.org, lev@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:49:28 -0000 On Tuesday, November 11, 2014 3:16:19 pm Charles Swiger wrote: > On Nov 11, 2014, at 10:57 AM, John Baldwin wrote: > > On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: > >> > >> After changing timezones in Russia (with replacing /etc/localtime > >> with new file), I found that cron works in "old" timezone till > >> restart. And all other services do the same, but cron is most obvious > >> here :) > >> > >> Looks like libc reads timezone only once and it could not be chamged > >> for process without restart (which leads to, effectivly, restart of > >> whole server). > >> > >> Is it known problem? I think, it should be fixed somehow. I > >> understand, that re-check timezone file on each time-related call > >> could be expensive, though :( > > > > In practice, timezone changes are very rare, so rechecking the file is > > quite expensive to do. I think having to restart processes is fine for this. > > In theory, timezone changes should be very rare. > > We've actually had about ten TZ updates in 2014; the most recent was FET -> MSK > for Belarus plus minor tweaks to IDT vs ICT. If you're working within the scope > of a single country, I suspect that one could ignore the bulk of TZ updates and > be fine most of the time. > > If you're world-wide, however, TZ update frequency becomes more noticeable.... The vast majority of updates are historical changes however. Having used a timezone-aware version of cron for an international company so we can schedule jobs across multiple timezones for a single machine (times N machines scattered around the globe) for the last 4 or 5 years, FET -> MSK was the first time we had a timezone change in that span that actually impacted our operations (and we've just restarted cron / rebooted to cope). -- John Baldwin