From owner-freebsd-current Sat May 12 10:25:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 8D1A737B423; Sat, 12 May 2001 10:25:15 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA61128; Sat, 12 May 2001 10:25:08 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3AFD71F3.905EC08C@DougBarton.net> Date: Sat, 12 May 2001 10:25:07 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Kirk McKusick , fs@FreeBSD.org, current@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] References: <20010511121020.B31232@sunbay.com> <200105111916.MAA16255@beastie.mckusick.com> <20010512023602.A40616@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > On Fri, May 11, 2001 at 12:16:18PM -0700, Kirk McKusick wrote: > > > At the moment there is no provision for notifying the system > > administrator since the output of fsck is simply being sent > > to the `logger' program (which by default will put the messages > > into /var/log/messages). You can feed 'logger' the -p option with a facility.level pair that will let syslogd decide how to handle it, although I agree that fsck should really use syslog() instead. > > It would be possible to add a syslog > > (or wall) call to the fsck program itself. Another alternative > > would be to have fsck forcibly downgrade the offending filesystem > > to read-only mode. However, if it were say the /var filesystem, > > the system would fall apart pretty quickly. I am open to > > suggestions on how best to proceed. > > Working under the assumption that the only time fsck is likely to fail > in this manner is if there are FS errors which can't be resolved in > the background, and which may result in further FS damage if left > uncorrected, the best option seems to be to take some action which > prevents this damage. > > The best series of actions might be the following: > > 1) Downgrade the FS to readonly mode. This is reasonable, and IMO even more important for an fs like /var that is likely to be written to early in the life of the system. > 2) syslog(LOG_EMERG, "Unrecoverable error in background check of %s, > FS downgraded to readonly mode. Reboot in 60 seconds to attempt to > repair the error. Kill PID %d now to abort.", ...) > > 3) Reboot in 60 seconds I'm not sure that always rebooting is a good idea however. This may be more effort than it's worth, but what about a flag in fstab that indicates something to the effect of, "This partition is essential to the system, reboot automatically to fix it?" For instance, if my /usr/obj partition comes up dirty, I can deal with it by hand, whereas if something important is hosed, I'd like the system to deal with it more drastically. We could default it to on, and let people load the foot-shooting gun themselves if desired. -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message