Date: Sat, 21 Feb 2015 20:30:33 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Perry Hutchison <perryh@pluto.rain.com> Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: make init(8) aware of /rescue/sh Message-ID: <20150221193033.GA10071@stack.nl> In-Reply-To: <54e81745.VJ9sLUeKwo661VPr%perryh@pluto.rain.com> References: <54db2f2f.gIXyruGSeJuY3FbJ%perryh@pluto.rain.com> <20150214234943.GB1360@stack.nl> <54e81745.VJ9sLUeKwo661VPr%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 20, 2015 at 09:27:33PM -0800, Perry Hutchison wrote: > Jilles Tjoelker <jilles@stack.nl> wrote: > > On Wed, Feb 11, 2015 at 02:30:07AM -0800, Perry Hutchison wrote: > > > Seems to me it might be desirable for init(8) to fall back > > > to /rescue/sh for single-user mode if neither the default > > > (kenv:init_shell) nor /bin/sh is usable. Thoughts? > [patch snipped] > > It is already possible to type "/rescue/sh" at the prompt > > (the Makefile always compiles with -DDEBUGSHELL). > Of course, provided one remembers that /rescue/sh exists :) > I use /rescue so rarely that I did not remember its existence > when this situation arose a little over a week ago. (I did, > however, remember that I have an emergency shell in /sbin; > worst case I would have booted off the distribution flash > drive, which I keep handy in case of boot troubles.) > Part of the reason for adding an automatic fallback to /rescue/sh > is to jog the admin's memory, in case something is messed up badly > enough that other parts of /rescue might also be needed. > > This must be done manually but also covers the case where > > /bin/sh exists but rtld or shared libraries are missing or > > broken. > That case is already covered, indeed it is exactly what led to > the incident mentioned above. (/bin/sh was fine, but one of its > shared libs was missing.) In that case, execve(2) will succeed, and the result as far as init is concerned is similar to sh starting properly and the user typing 'exit 1'. > > I'm not really sure this is worth the extra code. > If we follow that line of reasoning to its logical conclusion, > we should also remove the automatic fallback to _PATH_BSHELL. > After all, if the system fails to boot because kenv:init_shell is > set to something broken, one can always enter /bin/sh manually. > BTW the amount of "extra code" is trifling compared to the overall > size of init :) It does not seem unreasonable to me to remove the automatic fallback to _PATH_BSHELL. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150221193033.GA10071>