On 2/17/23 2:54 PM, Finn Thain wrote:
>
> On Fri, 17 Feb 2023, Stan Johnson wrote:
>
>> I noticed that /sbin/init seems to ignore SIGABRT, so I thought that
>> might mean that init itself was somehow triggering the stack smashing
>> but nothing was really aborting, but I could be wrong about that.
>
> Why do you say init ignores SIGABRT? I couldn't find that in the source
> code. Did you try 'kill -ABRT 1'?
>
Yes, what does the source code say about SIGABRT? I know SIGHUP causes
/etc/inittab to be re-read, and SIGKILL (and maybe SIGTERM?) kill it,
but I'm not familiar with the other signals.
root@maciifx:~# ps auxw | grep init
root 1 6.0 1.3 2524 1704 ? Ss 14:58 0:36 init [2]
root 854 28.1 1.5 7168 1908 pts/0 S+ 15:08 0:00 grep init
root@maciifx:~# kill -ABRT 1
root@maciifx:~# kill -6 1
root@maciifx:~# ps auxw | grep init
root 1 5.7 1.3 2524 1704 ? Ss 14:58 0:36 init [2]
root 856 26.6 1.5 7168 1908 pts/0 S+ 15:09 0:00 grep init
I expected an error such as "can't abort init", but there was no such
message, even at the serial console. That's not to say a SIGABRT is
ignored, it just doesn't kill PID 1.
According to the man page:
"Init reacts to several signals:
SIGHUP
Has the same effect as telinit q.
SIGUSR1
On receipt of this signals, init closes and re-opens its control
fifo, /run/initctl. Useful for bootscripts when /dev is
remounted.
SIGUSR2
When init receives SIGUSR2, init closes and leaves the control
fifo, /run/initctl, closed. This may be used to make sure init is
not holding open any files. However, it also prevents init from
switching runlevels. Which means commands like shutdown no
longer work. The fifo can be re-opened by sending init the SIGUSR1 signal.
SIGINT
Normally the kernel sends this signal to init when CTRL-ALT-DEL
is pressed. It activates the ctrlaltdel action.
SIGWINCH
The kernel sends this signal when the KeyboardSignal key is hit.
It activates the kbrequest action"
