0

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:

  1. 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?

  2. 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)

  3. 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."
3
  • Can you say which distribution you are using? I'd like to see if I can reproduce this but don't know what is acting as init here. It feels like the stein may not be your terminal but I can't tell without testing. – Philip Couling Nov 2 '19 at 20:56
  • Im using the yocto env , powerpc p4080ds SoC , centos dis – hutcruchi Nov 3 '19 at 6:32
  • I've not had chance to try this yet. As you are running this as a service I wonder if the service manager (systemd?) is running without stdin attached. You might want to write another test that checks what stdin is, see this answer stackoverflow.com/a/13544447/453851 if this comes up blank then it is a pipe and NOT attached to the terminal. – Philip Couling Nov 4 '19 at 7:08
0

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.

5
  • this is the /etc/inittab file (how can I write it in code format?): # The default runlevel. id:5:initdefault: si::sysinit:/etc/init.d/rcS # What to do in single-user mode. ~~:S:wait:/sbin/sulogin 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 – hutcruchi Nov 4 '19 at 6:22
  • my goal is that the inittab will run a process (or a script which will run the process) , but I need that process to run with "low" priviliges and that will be able to recieve ctrl z/x/c signals – hutcruchi Nov 4 '19 at 6:25
  • Not the inittab, I want to see the exact script you start your c program. You mean you need that process block the bootup process until you enter something or make a signal on the keyboard? You don't want to see the "login:" prompt until your process exit, right? – ZhouZhuo Nov 4 '19 at 6:31
  • Would you mind pasting the script in your question? It's not well-formatted in the comment. – ZhouZhuo Nov 4 '19 at 6:34
  • yes. I don't want to see the prompt until I exit the process. I attached the inittab and the script – hutcruchi Nov 4 '19 at 11:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.