From owner-freebsd-questions@freebsd.org Tue Dec 12 19:01:46 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78298E802D1 for ; Tue, 12 Dec 2017 19:01:46 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E77596BFC7 for ; Tue, 12 Dec 2017 19:01:45 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.18.98]) by mrelayeu.kundenserver.de (mreue101 [212.227.15.183]) with ESMTPA (Nemesis) id 0LZvrB-1esuhh2Okv-00lkRz; Tue, 12 Dec 2017 20:01:28 +0100 Date: Tue, 12 Dec 2017 20:01:26 +0100 From: Polytropon To: freebsd@dreamchaser.org Cc: Adam Vande More , FreeBSD Questions Subject: Re: Subject: Thunderbird causing system crash, need guidance Message-Id: <20171212200126.3ddf75e5.freebsd@edvax.de> In-Reply-To: <5fbcd05c-ce12-b1a4-a9e9-79276dad7183@dreamchaser.org> References: <201712110045.vBB0jCTQ078476@nightmare.dreamchaser.org> <38e2ef70-fa1b-25bf-4447-752006418d0a@dreamchaser.org> <20171211135803.d1aff6c8.freebsd@edvax.de> <5fbcd05c-ce12-b1a4-a9e9-79276dad7183@dreamchaser.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hWI6E52awnMmbI8nC+C8UGcOJ0kKstjJwAFb8NOyk1KHXyWIBQM dklLJuyNokP1276my2KgzNkHmLWWiHe3hq8J9RDJ3N9nmPLv4J06voQHc/xvLI+qIljEvJy dZZyddi3LjYjveqU6fzb21oqgnNrqUup+s0/YSLzzb3IBkQbCXGenB7lahmKb1EU4cp3+Ko uDaecdPXDmK+67eJnVWIg== X-UI-Out-Filterresults: notjunk:1;V01:K0:tvPfefsgfLg=:D3yHaTBGAShOqci3MSgFE8 eHl5Xs0TsJhBustV+tFqGbDojdOQJWIxS83iJ78Ws5Vs3TIdNhvSCyz96SFXfU0RQ6PScQ93E iOcvQ8/2BjLMVWbjEXIapvAc7EbiBYDWM9ur1WFsL1j4m4WMl5n7l8gmVa1AfUnGlqs/Qvv4m WZ3B63/tJN7Fa2HjERbiWCe6fNT+2xUrhV+sdBXlUR1Tuv0mgkUovmeK0P8ZP+9WBKhidLvwA PDxtDHhXZdPDmWXEUfjP88iPXknN78tTL2/6byrUtjI3RiAGws8g91U3QL4c3vayTVKIfUXgZ gYUlzPsVCaBKd+6qqoKfS9/Mlv1aSOllDY/mS+UdiDy7f3sgug8YbikjAhZiL+gH8pn4hZc5o pjgu6/ajxTRlhkCc6AYXUeTKmiLwrXcpQZuo74LO485hzNTgx07QX+mmsWmUkmsWRS62JB65S de5LiHNnWlTr0fkStrjnxuHXdrQYzOof1rYyxOE+MHYgX7QXsBURTkLSVCtfOAyM8FKm4hqZb Wn49tPUaLNHDkHtgIGzJdqquK9WOoI8HBQbbrG58XW+a8TleiJqTypD6UtJRjQESIg29UXRpR OxrxmJtwNXQtDvD+ORsL4rMIENIABOMmh2Bfz14e3FyggFW02KkV/QGL+fThC16tEiK4bRzJJ 1N/XcJ86Ntgj4kZb7T0heZwyoaoU5euQ2tZsPclaVRThyz0w1g0WpXtFv2Gvye/Pew0EtnFH/ qCa1X21M2d4YGVDj/EA7RPUQwW5Mu7kxx+d3GXJElz9FpAdUVi2rGY7J6dc= X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 19:01:46 -0000 On Tue, 12 Dec 2017 11:30:26 -0700, Gary Aitken wrote: > On 12/11/17 05:58, Polytropon wrote: > > On Sun, 10 Dec 2017 21:56:16 -0700, Gary Aitken wrote: > >> On 12/10/17 19:02, Adam Vande More wrote: > >>> On Sun, Dec 10, 2017 at 6:45 PM, Gary Aitken wrote: > > >> However, I'm confused. > >> Upon reboot, the system checks to see if file systems were properly > >> dismounted and is supposed to do an fsck. Since those don't show up > >> in messages, I can't verify this, but I'm pretty certain it must have > >> thought it was clean, which it wasn't. (One reason I'm pretty certain > >> is the time involved when run manually as you suggested). > > > > This is the primary reason for setting > > > > background_fsck="NO" > > Already had that set for just that reason. > > > in /etc/rc.conf - if you can afford a little downtime. > > The background fsck doesn't have all the repair capabilities > > a forced foreground check has, to it _might_ leave the file > > system in an inconsistent state, and the system runs with > > that unclean partition. > > > >> The file system in question was mounted below "/". > >> Does the system only auto-check file systems mounted at "/"? > > > > Yes, / is the first file system it checks. The two last > > fields in /etc/fstab control what fsck will check, and > > /etc/rc.conf allows additional flags for those automatic > > checks. > > The ordering part I understand; what I don't understand is why it (as I > recall) rebooted successfully with no warnings in spite of the > background_fsck="NO" being set and when one of the disks apparently > didn't fsck properly. I thought it should have halted in single-user > mode and waited for me to do a full fsck manually. Unfortunately, the > fsck output is not printed to the log, and I logged in as root on the vt0 > device, so it had scrolled off by the time I went to look for it. A > good reason never to log into the vt0 device. Is there any way to get > the "transient" boot-time fsck and other messages recorded in the log? There is an easy explanation: The foregroud fsck at boot time can only handle a subset of damages. In some cases, you are required to perform a second run of fsck in order to fix problems. This is where a forced full fsck is very useful (usually in single-user mode). You can specify additional flags for boot-time fsck via /etc/rc.conf, which are: fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails. fsck_y_flags="" # Additional flags for fsck -y background_fsck="YES" # Attempt to run fsck in the background where possible. background_fsck_delay="60" # Time to wait (seconds) before starting the fsck. For example, fsck_y_flags="-f" would be such an addition. As you can see, an initial preen ("limited fsck") can fail, and the filesystem might be in an inconsistent state. This is probably what you've been experiencing. See "man fsck" for details. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...