Date: Thu, 17 Jul 2003 05:43:10 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue Message-ID: <p05210671bb3c1bf6b8fd@[128.113.24.47]> In-Reply-To: <20030717080805.GA98878@dragon.nuxi.com> References: <20030717080805.GA98878@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05210671bb3c1bf6b8fd>