LinuxQuestions.org - trapping signals at bootup

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - trapping signals at bootup (https://www.linuxquestions.org/questions/slackware-14/trapping-signals-at-bootup-28544/)

trapping signals at bootup

Hi all,
this might go beyond the scope of a "newbie" question, but it likes like this is the best place to ask since slackware doesn't have their own forum anymore. I have a workstation that automatically logs in a user out of inittab. I believe the line is something like:

agetty -n -l /path/to/my/replacement/login

It automatically starts up X Windows, and I have that locked down as well. I have the users's stty settings set in such a way that they cannot CTRL+C, CTRL+Z, etc. out of anything. My only problem is right at startup... When /etc/rc.d/rc.M runs, and it goes through the "going multiuser...." stuff, if you start hitting CTRL+C and put a stop to the process before its finished running everything. This escapes the user to a prompt, but I don't want them to get a prompt.

Does anyone know of a way to prevent this from happening, and trapping those signals? Any pointers or suggestions will be much appreciated, even if its "hey, go ask these guys at this forum." Thanks!! B-)

./brm

I am not sure if this is what you are looking for directly or not. But in the /etc/passwd file the last item in the list for the specific account that you are using is the shell for that user account. Normally it is set to something like /bin/bash. Try setting it to something else. Like a bash shell script with the command logout.

You might also consider to use run level 4, instead of runlevel 3. That produces a GUI login prompt that can require a password for the users. Never leaving X windows. The users allowed to use the GUI can also be controlled or limited to just the users you desire. There is one getty on tty6 (Ctrl-Alt-F6 in X windows) that would need to be dealt with that would produce a login prompt. But if you remove the shell statement from their account in the password file I think it would disable their login at that prompt because it would not have a shell provided.

Perhaps the info will be of some assistance.

You can try to trap signals at the beginning of rc.M.

Code:

SigInt()

{

  echo "SigInt trapped"

}



trap "SigInt 2" INT

You may have to trap other signals that my break execution.

Excalibur & crabboy,

Thanks for the info there. I already have the users shell setup something like this:
---------
#!/bin/ksh
allowed_ttys="/dev/tty1"
real_shell="/bin/tcsh"
my_tty="$(/usr/bin/tty)"

eval [[ $my_tty != $allowed_ttys ]] && exit 1

exec -a -${real_shell##*/} $real_shell ${1+"$@"}
--------

the .login file for this particular user nullifies the stty settings for particular signals such as int, eof, etc. after it sets those, it starts xinit/X, and when X is done running it reboots the computer. (I have halt set to 4755).

The problem is when CTRL+C is hit while rc.M is running. As I said, people can break out of that and get a shell prompt before the faked "login" program that I set in inittab.

My "login program" is essentially 'su - user' which of course then runs the .login. CTRL+C circumvents this whole login process. I tried the runlevel 4 stuff, but that starts up xdm/gdm/kdm and presents the user with a login box. I need to have an autologin.

So I appreciate the info Excalibur, but I pretty much tried it already. It seems that you and I are of the same frame of mind. :-) Crabboy, I'll try your method and post another reply.

Thanks you two! I really do appreciate it. Take care.
./brm

Crabboy,

I just tried your approach and that seems to work. And I realized it wasn't breaking out of rc.M it was breaking out of rc.local which basically just says "echo 'Entering Kiosk Mode.....'" (or so this appears to be the case). So I added your SigInt() idea to both rc.M and rc.local

Now when rapidly hitting CTRL+C, it attempts to break, but then the respawn function in inittab that starts the agettys, says something about respawning too fast and that it won't do it again for another 5 minutes. So that's good!! :-D Thank you both very much for the help/suggestions.

./brm