Useful tools missing from /rescue

[Yar Tikhiy]

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