failsafe: fix console failsafe shell
When running a failsafe shell on a console, job control was unavailable,
and ^C did not function correctly.
This change invokes console failsafe shells via `setsid`, making them
session leaders and allowing them to claim controlling terminals, which
makes job control function properly. To support this, the busybox
`setsid` utility is enabled. This has a minimal 149-byte size impact on
a test x86_64 squashfs rootfs image.
^C was ignored in subprocesses of failsafe shells: it was not possible
to ^C out of a program that would not exit on its own, such as many
typical `ping` invocations. As job control was unavailable, it was not
possible to suspend these subprocesses either, causing a hung program to
tie up a console indefinitely, unless another means to signal the
program was available. This was caused by SIGINT being placed at
disposition SIG_IGN by the shell running preinit, which it did because
the console shell was executed asynchronously with &. That disposition
was inherited by the console shell and its subprocesses, generally
causing ^C to have no effect.
As there is no way in busybox `ash` to reset the disposition of a signal
already ignored at shell entry, and no apparent way to avoid SIGINT
being placed at SIG_IGN when & is used in preinit, an alternative
construct is needed. Now, `start-stop-daemon` is used to start (-S) the
console failsafe shell in the background (-b). This approach does not
alter SIGINT, allowing the console shell to be started with that
signal's handling intact, and normal ^C processing to occur.
busybox `ash` has some behaviors conditional on SHLVL, and while the
console shells ought to run at SHLVL=1, they were not by virtue of being
started by the shell-based preinit system. Additionally, a variety of
detritus was present in the console shell's environment, carried over
from preinit. These conditions are corrected by running the console
shell via `env -i` to clear the environment and establish a minimum and
correct set of environment variables for operation, in the same manner
as `login`. HOME is not explicitly set, because it's addressed in
/etc/profile. For non-failsafe console shells when
system.@system[0].ttylogin = 0, `login -f root` achieves a similar
effect. (`login` already started non-failsafe console shells when
ttylogin = 1 and behaved correctly. This brings the ttylogin = 0 case to
parity.) Note that even `login -f` is somewhat undesirable for failsafe
shells because it requires a viable /etc/passwd, hence the `env -i`
construct in that case.
The TERM environment variable from the preinit environment, with value
"linux", would rarely be correct for serial consoles. Now, the preinit
TERM value is preserved (or set to "linux" if unset) only when the
console is /dev/console or /dev/tty[0-9]*. Otherwise, it will be set to
a safe default appropriate for serial consoles, "vt102", as used for
serial consoles by busybox init. This "linux"/"vt102" TERM setting is
also duplicated for non-failsafe console shells.
This also indicates failsafe mode by showing "- failsafe -" on all
consoles (not just the last-defined one). It sets a hostname of
"OpenWrt-failsafe" in failsafe mode which is rendered in the shell's
prompt as a reminder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-default
hostname, "(none)", appearing in failsafe shell prompts.
Signed-off-by: Mark Mentovai <mark@mentovai.com>
Link: https://github.com/openwrt/openwrt/pull/16113
Signed-off-by: Robert Marko <robimarko@gmail.com>