Date: Sat, 12 May 2001 10:25:07 -0700 From: Doug Barton <DougB@DougBarton.net> To: Kris Kennaway <kris@obsecurity.org> Cc: Kirk McKusick <mckusick@mckusick.com>, fs@FreeBSD.org, current@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <3AFD71F3.905EC08C@DougBarton.net> References: <20010511121020.B31232@sunbay.com> <200105111916.MAA16255@beastie.mckusick.com> <20010512023602.A40616@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AFD71F3.905EC08C>