7

I don't know if "single user mode" is the correct term for that but here I go:

On the GRUB menu, I pressed E to edit the run configurations. To the line that starts with linux, I have appended the following:

rw init=/bin/bash

and pressed F10. The computer boots up to a root shell without asking any password.

The problem is, signals are not working. For example, when I run a command, I cannot exit from that command by pressing Ctrl + C.

Is this expected? If yes, what is the reason for this and how can I fix this? Is it related to the terminal emulator in single user mode?

Utku
  • 1,433
  • fwiw, running a second bash process, i don't observe ctrl+c being respected, but if you can remount rw, using tmux appears to enable ctrl+c somehow. of course, this is untested and, Surely, bad advice – ThorSummoner Oct 02 '22 at 02:00

2 Answers2

4

Single user mode has not been the right term for quite some time. In the 1990s, what used to be single user mode split into emergency mode and rescue mode. You are not in fact using either one.

What you are actually doing is a poor idea, because it involves running a program as process #1 that is not designed to do the jobs that process #1 actually needs to do. You would be better off using emergency or rescue modes, the latter of which is invoked by the accepted answer that the answer that you point to, itself points to.

Yes, signals will act oddly. Process #1 has special semantics for signals, for starters, which is one of the several reasons that init=/bin/bash is a poor idea. Furthermore, job control shells cannot do job control when /dev/console is their standard I/O but nothing has set up a proper session with a controlling terminal, as the Bourne Again shell actually told you as soon as it started up.

It is possible with some simple chain-loading tools to set up a proper session with a controlling terminal, and thence enable job control and signal delivery to a foreground process group, but that does not fix all of the other things that will go wrong with /bin/bash as the process #1 program because you have to carefully do them explicitly, by hand.

Just use rescue mode or emergency mode.

Further reading

JdeBP
  • 68,745
  • The first link says that both modes provide a secure login. What if I have forgotten the password? In that case, my only option is init=/bin/bash, right? – Utku Dec 12 '17 at 23:22
  • Wrong. You then have the option of Recovery Mode, which is mentioned as another answer beside the one that you point to. – JdeBP Dec 13 '17 at 10:37
  • great info,, would love more info on how to boot into recuse/emergency mode in a way that bypasses systemd though, since its often the reason i'm here in the first place. – ThorSummoner Oct 02 '22 at 01:52
1

As others have mentioned, /dev/console doesn't always function as a true tty, which restricts job control.

But as a practical matter, you can simply start a shell that is connected to a tty ...

/usr/bin/setsid /bin/bash -ilm <> /dev/tty9 >&0 2>&0 &

... and then hit alt-F9 to switch to VT#9 where the new shell should be running, with job control enabled. (You can pick any VT that's not already in use, just change all three 9's above to whatever you want to use.)

As a separate matter, the shell being PID 1 means that it inherits every orphan process; most shells can cope with this, because they have to be able to cope with the situation where a child process was created before the execve call to launch the shell itself, but it's possible that some may get confused, or do weird things like ignoring SIGCHLD when they don't think they have any outstanding children. For these it may help to leave this running while you work in your other shell:

while : ; do wait ; done
Martin Kealey
  • 560