Useful tools missing from /rescue

[David O'Brien]

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 at FreeBSD.org)