2

With kernel 3.10.55 I can break a Linux boot process by pressing Ctrl + C.

But with the newest kernels (4.1 and 4.4) Ctrl + C in boot time does not work – it displays ^C but does not break init script.

I use Slackware 64 14.1 and have a simple test for it: add in my rc.local file the following commands:

echo "Test for Control-C - if does not work then press Enter"
read

And I need to press Enter to continue boot process.

Kamil Maciorowski
  • 74,068
Slackware User
  • 21
  • If I launch ./rc.local with read command after finishing boot process Control-C works, but does NOT work in boot time. – Slackware User Jan 10 '17 at 11:14
  • 2
    Why would you actually do this? – Seth Jan 10 '17 at 12:03
  • I have a specific boot image that launches a specific server software. But sometimes I need to load only bare linux system without this software and pressing Control-C in a specific boot period allows me to do this. – Slackware User Jan 13 '17 at 13:52
  • I used stty to set isig but this does not work well. – Slackware User Jan 13 '17 at 13:53
  • 2
    Why not provide an additional boot entry that just boots into single user mode or a lower run level? – Seth Jan 13 '17 at 18:44
  • Yes< I can always do it. But it is more preferable for me to use Control-C. It works ealier and does not work now. – Slackware User Jan 16 '17 at 07:50
  • What do you mean the approach of using stty didn't work well? What command did you actually use? Why do you think it's part of the kernel update? Did you check your init scripts for differences? This and this would indicate it might be a problem with your init scripts. – Seth Jan 16 '17 at 08:19
  • Thanks for the response. My test rc.local is simple - echo "testing" and read command. If I execute it after being logged in I can break it by using Control-C and I cannot break it if it was being launched as a part of boot proccess. I tried stty -a to get tty setting - and they are identical in the both cases. Also if I logged in using ssh I can kill -SIGINT <pid_of_read> but pressing Control-C prints ^C on the screen but do not terminate the process. Init scripts stay the same as I changed only kernel and its modules. – Slackware User Jan 16 '17 at 13:21
  • How did you upgrade the kernel? If it was an automatic script it might have touched certain bits and pieces. Did you run stty -a as a your current user? if so have a look if you include it in your init file. After all you're not logged in, in a traditional sense during boot. In addition you could compare the loaded modules and builtin modules. Maybe some driver is just loaded as a module now rather than builtin? – Seth Jan 16 '17 at 13:37
  • I have upgraded the kernel manually - simply by coping itself kernel file and /lib/modules/<new_ver> + depmod <new_ver> from another computer. There is another strange thing - if I logged in by using ssh and executed strace -p <pid_of_the_read> and press Control-C in the boot console nothing happens except printing ^C on the screen. But if I executed from another ssh session kill -SIGINT <pid_of_the_read> strace shows how the waiting process is reacting. Therefore the problem must be in tty driver that treats Control-C in boot time and does not allow to generate SIGKILL. – Slackware User Jan 17 '17 at 08:10
  • 2
    So did you include stty -a in your script and have a look whenever ^C is bound to the right thing? ^C would normally not trigger a SIGKILL to begin with but rather SIGINT or maybe SIGTERM. Maybe this would be better suited for Unix Stackexchange? – Seth Jan 17 '17 at 09:10

2 Answers2

0

Finally, I have managed to make Control-C works in the boot time. BUT the solution is a hack :( During boot time the startup scripts have /dev/console as their stdin/stdout and it cannot be tuned by stty. The problem is in setting this device as NOCTTY in kernel module tty_io.c. Simply changing *noctty = 1 to 0 and rebuilding kernel works fine for me.

Slackware User
  • 21
-2

Run

ps aux | grep < your process name >

The first set of numbers in the result list of each line is your pid.

Run

kill < pid number >

To kill that process

KingsInnerSoul
  • 205
  • 2
    you don't have an interactive shell during boot. – Journeyman Geek Jan 11 '17 at 03:41
  • Thanks for the answers. BUT this is a boot process and I am still not logged in. And how to set up interactive shell for the booting process? It is very disappointing that for one kernel it works and does not work for another and I do not know where to find info about these changes. – Slackware User Jan 13 '17 at 13:45
  • If I logged in using ssh and exes kill -2 <pid_of_read_from_boot_script> it kills the process, but Control-C pressed in the boot console does not. May be it specially treats in tty driver during boot time. – Slackware User Jan 13 '17 at 14:54