From owner-freebsd-arch@FreeBSD.ORG Thu Jul 17 02:43:14 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65B2D37B404 for ; Thu, 17 Jul 2003 02:43:14 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 538FE43F85 for ; Thu, 17 Jul 2003 02:43:13 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h6H9hCCx031628 for ; Thu, 17 Jul 2003 05:43:12 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030717080805.GA98878@dragon.nuxi.com> References: <20030717080805.GA98878@dragon.nuxi.com> Date: Thu, 17 Jul 2003 05:43:10 -0400 To: freebsd-arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2003 09:43:14 -0000 At 1:08 AM -0700 7/17/03, David O'Brien wrote: >This is a list of binaries that I don't feel should be part >of /rescue as it's mission is to recover/rebuild a "broken" / >[due to all the binaries being dynamic]. Is there >justification for keeping them? >- date, one can use a watch if they really want to know it > is 5am and their system is down. In my experience, it is often useful to be able to keep timestamped logs during any system repair operation. They can be useful when you go to review what happened (at some later time, after you have caught up on your sleep). >- sleep, this is what the admin wishes he was doing at 5am > rather than trying to recover a borked system. The admin > doesn't need the OS sleeping and delaying the repair. For both 'date' and 'sleep', I would like to have them around just in case I run some script which happens to reference them. I admit this is just a "feel good" reason, I can't give a specific example where this would come up in the middle of repairing '/'. A far as the rest of the files in your list, I can't think of any reason I would need them to be in /rescue. That's just my opinion, of course. It does make sense to keep /rescue as small as possible. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu