Date: Mon, 15 Oct 2007 10:38:26 -0700 From: "David O'Brien" <obrien@freebsd.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-hackers@freebsd.org Subject: Re: Useful tools missing from /rescue Message-ID: <20071015173826.GA88628@dragon.NUXI.org> In-Reply-To: <20071013060138.GA14388@comp.chem.msu.su> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. /stand was a left-over from installation and not intended to be a sysadmins' savor - it just happened to be because we didn't clean up / after the bits were laid down. > 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 /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. > 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. > 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-) > > 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. -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071015173826.GA88628>