Process Ignores Signals + Terminal/Shell Concept

Question

I'm using linux kernel 4.1.8 32bit.

My init process (using /etc/inittab and /etc/rd5.d Scripts) run the "Hello" process during boot time:

int main(){
     int val;
     printf("Hello\n");
     scanf("%d",val);
     return 0;
}

(with all the necessary includes to work with linux,signals,i/o...)

My problem is both practical and conceptual:

practical:

1. This process ignores the ctrl z/x/c signals only when it executes via the init scripts and before the login process. If I run it after I login into shell - all works fine. Additionally, I added some code to it to run the: "ps -eo pid,lstart,cmd" command and I saw that during its execution at init time there is no shell process exists.

Conceptual:

2. At first I thought the shell is the one responsible for sending signals to the process. From reading other posts I understood that's incorrect and the one responsible is the terminal console. The thing is that terminal console is not a process. Its just some kind of CLI "GUI". By that I mean that a shell without a terminal can run and executes scripts without the user awareness and a terminal without a shell can do nothing.. maybe only shows a prompt or something? but in order for our input to impact in some way - command or an interrupt we need a shell that will read and interpret our input. isn't that right?

3. What am I missing here? and if the reason for my process ignoring these signals is not related to the fact that it executes before the login process and before my interactive shell opens , then what it could be? (again, if i run it after my shell opens and not part of the init scripts then everything works fine)

4. Is there any literature explaining this topic?

edit:

/etc/inittab:

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $
# The default runlevel.
id:5:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
S0:12345:respawn:/sbin/getty -L 115200 ttyS0

script inside /etc/init.d/rcS folder:

# source function library
. /etc/init.d/functions
        echo "Starting gripen applications"
    cd /appsys/bin
    /bin/sh -c ./testApp
    echo "done."

Answer 1

I don't know your exact situation from the information you post, so let me answer some of your conceptual confusions first.

command or an interrupt we need a shell that will read and interpret our input. isn't that right?

No. A shell is not necessary needed for passing a keyboard-generated signal (like Ctrl-C). To receiving the keyboard-generated signal -

• your process need to be a foreground process;

• your process need to have a controlling terminal.

A running foreground process will block its terminal and grab current input from the terminal.

Generally a login process ls launched by a getty command, processes ran by your logged-in shell take the terminal specified by getty as their controlling terminal. Before login, you early init processes take the kernel console terminal as their controlling terminal by default.

You can learn more about this in APUE 3rd edition Chapter9.

Back to your situation, normally, programs in /etc/rc?.d are able to receive keyboard-generated signals from kernel console terminal. I suggest you to post your init script for us to see how your program started.

Hope this helps.