From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2249 Path: news.gmane.org!.POSTED!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.os.freebsd.devel.hackers,gmane.comp.sysutils.supervision.general Subject: Re: Linuxisms in s6 Date: Sat, 27 Aug 2016 17:51:55 +0100 Message-ID: <482f9512-2634-74e5-ac72-45d3a344eee1@NTLWorld.com> References: <37d5159b-4957-42f8-2252-fa53d7446bb6@NTLWorld.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1472316740 31945 195.159.176.226 (27 Aug 2016 16:52:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Aug 2016 16:52:20 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 To: Adrian Chadd , Supervision , FreeBSD Hackers Original-X-From: owner-freebsd-hackers@FreeBSD.org Sat Aug 27 18:52:15 2016 Return-path: Envelope-to: freebsd-hackers@m.gmane.org Original-Received: from mx2.freebsd.org ([8.8.178.116]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdgq6-0007p6-DP for freebsd-hackers@m.gmane.org; Sat, 27 Aug 2016 18:52:14 +0200 Original-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 mx2.freebsd.org (Postfix) with ESMTPS id D28BC2C9A; Sat, 27 Aug 2016 16:52:14 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Original-Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A2D31FC3; Sat, 27 Aug 2016 16:52:14 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Original-Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9224BB77D96 for ; Sat, 27 Aug 2016 16:52:08 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Original-Received: from know-smtprelay-omc-4.server.virginmedia.net (know-smtprelay-omc-4.server.virginmedia.net [80.0.253.68]) by mx1.freebsd.org (Postfix) with ESMTP id DC398F59 for ; Sat, 27 Aug 2016 16:52:07 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Original-Received: from [192.168.1.100] ([86.10.211.13]) by know-smtprelay-4-imp with bizsmtp id cGs61t00N0HtmFq01Gs6SW; Sat, 27 Aug 2016 17:52:06 +0100 X-Originating-IP: [86.10.211.13] X-Spam: 0 X-Authority: v=2.1 cv=KbMvylsD c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=danhDmx_AAAA:8 a=Br9LfDWDAAAA:8 a=07d9gI8wAAAA:8 a=dZwYQNWPF_19G2bF6zYA:9 a=QEXdDO2ut3YA:10 a=P4VdviVPEcjfz_PVVggX:22 a=gR_RJRYUad_6_ruzA8cR:22 a=e2CUPOnPG4QKp8I52DXD:22 In-Reply-To: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: owner-freebsd-hackers@freebsd.org Original-Sender: owner-freebsd-hackers@freebsd.org Xref: news.gmane.org gmane.os.freebsd.devel.hackers:57957 gmane.comp.sysutils.supervision.general:2249 Archived-At: Adrian Chadd: > [...] the uptime stuff really threw us. > It's unfair to lay such system time problems at s6's door. Systems whose system clock jumps 46 years during system bootstrap don't get to blame s6 for mad time gaps that appear in logs and service start time records. There is a *lot* of the Unix and Linux worlds that depends from time being right. It's not just s6 that is affected by such things. You note crypto. There are a lot of other things as well that have unstated, sometimes undocumented, and sometimes surprising dependencies upon system time being current. Here's one such. For quite a while, Linux distributions had rather an odd problem at bootstrap. They'd repeatedly fsck volumes at every bootstrap when they need not have. And this didn't affect U.S. or U.K. people, which is in part why it persisted for so long. * https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/63175 * https://bugs.archlinux.org/task/17438 * http://lwn.net/Articles/264498/ The problem was that people were erroneously running their real-time clocks in local time rather than UTC, and this triggered an odd hidden dependency upon having the right time in the system clock in countries where local time was in advance of UTC. The Linux method for handling RTCs erroneously running in local time is for the system bootstrap to make a special settimeofday() call that effectively tells the kernel what the UTC offset is for the RTC hardware. This could happen *after* the fsck of the root volume, however. So whilst that fsck was happening, the kernel was assuming that UTC was the local time that it had taken from the RTC and initialized its system clock with. In effect, as soon as the special settimeofday() call was executed, the system clock would jump backwards by one or more hours, to what UTC actually was. But the ext2/3/4 filesystem format has last checked/mounted/written timestamps in its superblock. Part of the checking to see whether a full fsck is needed at bootstrap is comparing them to the current time. If they are in the future by hours or more, something is clearly wrong, thinks fsck, and it runs the full check. At bootstrap, when the initial fsck (of at least the root volume and sometimes other volumes as well) is run, the system clock is not UTC yet. Comedy results. Both systemd and the nosh system manager have to ensure that they do the special settimeofday() system call before they start off service management and thus run mount/fsck services, or indeed anything else that might have a closet dependency from not stepping the system time by hours partway through bootstrap. The nosh system-manager's manual page has a whole section on this subject. FreeBSD/PC-BSD has a mechanism for correctly reading a RTC that is erroneously in local time. One sets up the RTC's offset from UTC in the machdep.adjkerntz variable in /boot/loader.conf{,.local} and the system clock never has to jump by hours during bootstrap. I've yet to experience a FreeBSD/PC-BSD system where the installer actually configures this, though. Interestingly, FreeBSD/PC-BSD also has a fallback mechanism that uses the latest volume mount timestamp that it can find as the initial system time when no hardware clock device registers at bootstrap. Presumably you have a clock device that registers but it is not battery-backed, your volumes don't preserve (or reset) their mount timestamps, or you are encountering the comedy situation where FreeBSD/PC-BSD is setting the system clock to 1970-01-01 because the last time around it mounted the filesystems before the clock was corrected. _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"