Date: Sat, 14 Apr 2012 17:02:53 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Robert Huff <roberthuff@rcn.com> Cc: Alexander Best <arundel@freebsd.org>, freebsd-current@freebsd.org, Jeremie Le Hen <jeremie@le-hen.org> Subject: Re: howto debug a complete hard reset Message-ID: <20120414150253.GB71196@felucia.tataz.chchile.org> In-Reply-To: <20361.29886.740093.455933@jerusalem.litteratus.org> References: <20120414090728.GA8798@felucia.tataz.chchile.org> <20361.29886.740093.455933@jerusalem.litteratus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 14, 2012 at 08:59:42AM -0400, Robert Huff wrote: > > > This is probably a sysctl handler that is causing the reboot. You can > > run this one-liner to spot the culprit (use sh): > > > > for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done > > > > Each sysctl will be called in turn and the output is appended to > > a file, but the file will forcibly written to the disk before the > > next occurence. > > Um ... it is my understanding sync(8) does not guarantee > pending i/o will be written before it returns, but merely requests > this happen irrespective of when it would normally occur. > An I mistaken? Honestly I don't know, but I have do admit that the small paragraph in the BUGS section of the sync(2) manpage is a little bit shivering: BUGS The sync() system call may return before the buffers are completely flushed. Can any enlightened person answer this? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120414150253.GB71196>