Date: Thu, 18 Oct 2007 02:04:21 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: obrien@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Useful tools missing from /rescue Message-ID: <20071017220421.GD25575@comp.chem.msu.su> In-Reply-To: <20071015173826.GA88628@dragon.NUXI.org> References: <20070901073440.GL85633@comp.chem.msu.su> <46DAFE5C.6070806@freebsd.org> <20070903120353.GH30502@comp.chem.msu.su> <200709261028.43378.jhb@freebsd.org> <20071004022344.GA60878@dragon.NUXI.org> <20071013060138.GA14388@comp.chem.msu.su> <20071015173826.GA88628@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: > On Sat, Oct 13, 2007 at 10:01:39AM +0400, Yar Tikhiy wrote: > > On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: > > > I also don't see the need for pgrep - I think needing that says your > > > system is running multiuser pretty well. > > > > First of all, I'd like to point out that /rescue doesn't need to > > be as minimal as /stand used to. Now, /rescue is a compact yet > > versatile set of essential tools that can help in any difficult > > situation when /*bin:/usr/*bin are unusable for some reason, not > > only in restoring a broken system while in single-user mode. A > .. > > As for pgrep+pkill, it can come handy if one has screwed up his > > live system and wants to recover it without dropping the system to > > single-user. > > But if we take this just a little bit farther then why don't we go back > to a static /[s]bin except for the few things one might need LDAP, etc.. > for? That is, what's the purpose in continuing to duplicate /[s]bin > into /rescue? /rescue should be just enough to reasonably get a system > who's shared libs are messed up working again. Note that /rescue includes the most essential tools from /usr/[s]bin, too. Irrespective of its initial purpose, I regard /rescue as an emergency toolset left aside. In particular, it's good to know it's there when you experiment with a live remote system. > > A valid objection to this point is that pgrep's job > > can be done with a combination of ps(1) and sed(1), so it's just a > > matter of convenience. > > I guess I'm still having trouble understanding why one would need 'ps' > to fix a shared libs issue. Now is a reason to keep adding stuff to IMHO it isn't only shared libs issues that /rescue can help with. > /rescue. Also why one would be running 'ps -aux', which is the only way > I can think of to get more than one screen of output if a system is in > trouble. Imagine that you've rm'ed /usr by accident in a remote shell session. With enough tools in /rescue (which doesn't take lots of tools,) you can stop sensitive daemons, find the backup, restore from it, and get a functional system again without a reboot. No doubt, some tools just make the task easier by providing typical command-line idioms. I don't mean I'm so reckless that I need to restore my /usr often, but the 3-4 megabytes occupied by /rescue are a terribly low price today for being able to shoot different parts of one's foot without necessarily hitting the bone. > > The price for it in terms of disk space is next to nothing, and there > > are quite useless space hogs in /rescue already (see below on > > /rescue/vi.) > > Considering how few people are skilled in ed(1) these days, we have > little choice but include vi. Of course, there should be /rescue/vi, and I have an idea on how to remove its dependence on /usr in a more or less elegant way. I mentioned the not-so-functional /rescue/vi here just to show that we can tolerate certain space waste in /rescue. > > I won't speak for everyone, but I really like to use fancy shell > > commands, particularly during hard times: loops, pipelines, etc. > > So I don't have to enter many commands for a single task or browse > > I guess I'm not creative enough in the ways I've screwed up my systems > and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) > > > I don't see the purpose of chown - if you have to fall back to /rescue > > > you're user 'root' - and you're trying to fix enough so you can use > > > standard /*lib & /*bin > .. > > Having /rescue/chown is just a matter of completeness of the ch* > > subset of /rescue tools because chown's job can't be done by any > > other stock tools. If /rescue is complete enough, one can find > > more applications for it. E.g., the loader, a kernel, and /rescue > > /rescue wasn't intended to be well orthogonal. /rescue was part of he > corner stone of the deal to switch to shared /[s]bin. But it doesn't confine us to the corner forever. Having an emergency toolset independent of the rest of the system is good in any case. I bet people will experiment and have fun with their systems more eagerly if they know they still can recover quickly with ready tools in case of a serious error. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017220421.GD25575>