Useful tools missing from /rescue
yar at comp.chem.msu.su
Fri Oct 12 23:37:59 PDT 2007
On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote:
> > > > Yar Tikhiy wrote:
> > > > >I've had to use /rescue recently and felt lack of a few basic tools
> > > > >in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
> > > > >e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
> > > > >tail(1), and even tee(1) can be emulated if one has sed(1), but the
> > > > >tools are so tiny and convenient that it's a pity not to have them
> > > > >all handy during hard times.
> 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
skillful admin needs a rather limited number of tools, but some of
them still are missing from /rescue.
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. 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. 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.)
> Also head and tail - why not just add 'more' as that would give more
> functionality if you're trying to read a file in /etc to fix something.
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
through voluminous output for relevant parts. And it's hard to use
pipelines w/o basic filters. Again, head(1) and tail(1) can be
substituted by sed(1), but my fingers are just used to type "head"
or "tail" in certain cases. I suspect that I'm not the only one
of this kind out there.
As for more(1), there is a reason not to include it in /rescue now,
besides its rather large size. Namely it uses ncurses and thus
depends on /etc/termcap to work well; but in a really tough case
when you can mount only /, /etc/termcap is unavailable because it's
a symlink to under /usr. This problem plagues /rescue/vi already
(see PR bin/80256.) I think we should postpone adding more(1) to
/rescue to after the problem has been fixed. And, of course, more(1)
is no substitute for head(1) or tail(1) when it comes to pipelines.
> > > > >In addition, there are chflags and chmod in /rescue, but there's
> > > > >no chown in it, so the toolset is a bit incomplete.
> 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
> chflags is needed so you can overwrite a file and chmod is needed so you
> can "chmod +x" something - those needs are clear.
> Please don't pestimize the build - unless there is a clear benefit.
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
are enough to run single-user and do basic things. (Note that there
Of course, what I've just told is my own view of /rescue's role,
but it seems to be supported by some other folks.
Thank you for your comments! I think this discussion can let us
understand better what we need from /rescue.
More information about the freebsd-hackers