Unix Programming - Signal Handling problems

Author

Signal Handling problems

Karthik

2004-06-16, 5:57 pm

hello everyone,

I have been programming an init program based on the existing init
programs. I am facing some problems with the signal handling mechanisms.

I have a few signals setup to be handled by the program. If i execute
the program in userspace [simulation-mode], all the signals are being
handled fine, but when i execute the same code as the init program,
whenever i send a signal the Kernel panics and crashes the machine.

This occurs for all the signals that are setup to be handled by the
program. This is on a 2.6.4 kernel on Mandrake 10.

Is there anything spl that needs to be done for the init program ?? . I
dont think so and i have confirmed this with the existing programs also
...they do not do anything spl as far as i can observe.

what am i missing here ?? , any pointers would be really helpful

TIA

karthik

Nick Landsberg

2004-06-16, 5:57 pm

Karthik wrote:

> hello everyone,
>
> I have been programming an init program based on the existing init
> programs. I am facing some problems with the signal handling mechanisms.
>
> I have a few signals setup to be handled by the program. If i execute
> the program in userspace [simulation-mode], all the signals are being
> handled fine, but when i execute the same code as the init program,
> whenever i send a signal the Kernel panics and crashes the machine.
>
> This occurs for all the signals that are setup to be handled by the
> program. This is on a 2.6.4 kernel on Mandrake 10.
>
> Is there anything spl that needs to be done for the init program ?? . I
> dont think so and i have confirmed this with the existing programs also
> ..they do not do anything spl as far as i can observe.
>
> what am i missing here ?? , any pointers would be really helpful
>
> TIA
>
> karthik
>

I'm not exactly sure what it is that I think I saw you say up
there.

Is it that you have a program which works perfectly correctly
when run in user space and then when you link that same code
into the kernel you are having problems?

Please be more specific rather than speculating. There are
probably quite a few kernel hackers out there who can help
given more information.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

Karthik

2004-06-17, 5:55 pm

Nick Landsberg wrote:
> Karthik wrote:
>
>
> I'm not exactly sure what it is that I think I saw you say up
> there.
>
> Is it that you have a program which works perfectly correctly
> when run in user space and then when you link that same code
> into the kernel you are having problems?
>
> Please be more specific rather than speculating. There are
> probably quite a few kernel hackers out there who can help
> given more information.
>
>

I am writing my version of the /sbin/init program. The signal handlers
are not working as they are supposed to be work. I have a version of the
program which runs on user-space like a normal program where it does
not execute any bootup scripts or perform any system initialization
tasks. During this simulation run the signal handlers work perfectly as
i had expected.

When i replace the /sbin/init with my program the system boots up fine.
I am assuming that the signal handlers are working as my SIGCHLD handler
works properly as the getty processes are restarted when they terminate.
When i issue a SIGUSR1 signal from the command prompt it displays the
message:

"User defined Signal 1"
"Kernel Panic: trying to kill init"

and the system crashes. I dont understand why this occurs ?, I have a
handler for the SIGUSR1 signal installed in the program. I am running my
program using the 2.6.4 kernel on Mandrake 10. I am not sure what i am
doing wrong in this case, thats why i was asking whether any special
needs to be done for the "init" program. I did not observe anything
being done in the existing "init" programs.

My code is:

--------

void shutdown_system(int signo)
{
log_msg("SIGUSR1 was caught\n");
}

/* Setup signal handling */
sa.sa_flags=SA_RESTART;
sigfillset(&sa.sa_mask);
sa.sa_handler=SIG_IGN;
for (c=0; c < NSIG; c++) sigaction(c, &sa, NULL);

sa.sa_handler=sigtstp_handler;
sigaction(SIGTSTP, &sa, NULL);

sa.sa_handler=sigchld_handler; /* Handles zombies */
sigaction(SIGCHLD, &sa, NULL);

sa.sa_handler=sigint_handler;
sigaction(SIGINT, &sa, NULL);

sa.sa_handler=sigquit_handler;
sigaction(SIGQUIT, &sa, NULL);

sa.sa_handler=shutdown_system;
sigaction(SIGUSR1, &sa, NULL);

sa.sa_handler=shutdown_system;
sigaction(SIGTERM, &sa, NULL);

/* Setup CAD handling */
ioctl(STDIN_FILENO, KDSIGACCEPT, SIGWINCH);
reboot(RB_DISABLE_CAD); /* If CAD, send SIGINT and not reboot */
------------

Any pointers would be helpful.

TIA

Karthik

Villy Kruse

2004-06-17, 5:55 pm

On Wed, 16 Jun 2004 18:45:17 -0400,
Karthik <karthik@nospam.com> wrote:

>
> When i replace the /sbin/init with my program the system boots up fine.
> I am assuming that the signal handlers are working as my SIGCHLD handler
> works properly as the getty processes are restarted when they terminate.
> When i issue a SIGUSR1 signal from the command prompt it displays the
> message:
>
> "User defined Signal 1"
> "Kernel Panic: trying to kill init"
>

This may be a kernel problem. Rather than chrashing it would perhaps
be better to log the fact and keep going. If, on the other hand, the init
process realy goes away, the system would be pretty much hosed anyway.

You might consider an alternative IPC mechanism such as a unix domain
socket or a fifo (named pipe), just like the real init program does.

Villy

Karthik

2004-06-17, 5:55 pm

Villy Kruse wrote:
> On Wed, 16 Jun 2004 18:45:17 -0400,
> Karthik <karthik@nospam.com> wrote:
>
>
>
>
>
> This may be a kernel problem. Rather than chrashing it would perhaps
> be better to log the fact and keep going. If, on the other hand, the init
> process realy goes away, the system would be pretty much hosed anyway.
>
> You might consider an alternative IPC mechanism such as a unix domain
> socket or a fifo (named pipe), just like the real init program does.
>
> Villy

Other init programs also use signals for shutting down the system and to
handle the CTRL+ALT+DEL keystroke, etc.,. I think i am making some
mistake in the process group or session related stuff. I will make a
thorough comparison of my program and the other init programs to see
what i am doing wrong.

This question arises coz the same handlers work fine in User-space, so
there must be something special that i will have to do in terms of
process groups and sessions. I will post it back if when i figure it
out. In the meanwhile if somebody has some other suggestions it would be
helpful too.

TIA

karthik

Villy Kruse

2004-06-20, 10:32 pm

On Thu, 17 Jun 2004 12:18:08 -0400,
Karthik <karthik@nospam.com> wrote:

>
> Other init programs also use signals for shutting down the system and to
> handle the CTRL+ALT+DEL keystroke, etc.,. I think i am making some
> mistake in the process group or session related stuff. I will make a
> thorough comparison of my program and the other init programs to see
> what i am doing wrong.
>
> This question arises coz the same handlers work fine in User-space, so
> there must be something special that i will have to do in terms of
> process groups and sessions. I will post it back if when i figure it
> out. In the meanwhile if somebody has some other suggestions it would be
> helpful too.
>
> TIA
>
> karthik
>

After studying the kernel you will get the message

"Kernel Panic: trying to kill init"

If and amd only if the init program terminates for any reason. In other
words the init process may never ever terminate, except by the kernel
going into halt or power down. If you catch a signal and that leads
directly or indirectly to calling exit() then you do get this panic.
If your program calls exit() you will get it as well. If your main()
returns your kernel will also panic.

So it is not the signal handler that is the problem, it is what happens
afterwards.

Villy

Karthik

2004-06-26, 10:10 am

Villy Kruse wrote:
>
>
> After studying the kernel you will get the message
>
> "Kernel Panic: trying to kill init"
>
> If and amd only if the init program terminates for any reason. In other
> words the init process may never ever terminate, except by the kernel
> going into halt or power down. If you catch a signal and that leads
> directly or indirectly to calling exit() then you do get this panic.
> If your program calls exit() you will get it as well. If your main()
> returns your kernel will also panic.
>
> So it is not the signal handler that is the problem, it is what happens
> afterwards.
>
> Villy

True, i agree. The actual message that gets printed is:

"Kernel Panic: Attempted to kill init"

which is in the do_exit() function of the kernel.

My view of the problem lying in the signal handler is because in all of
the signal handlers i have a routine which prints:

"SIGNAL <whatever> was caught"

to the system console. When i issue a SIGTSTP or a SIGCONT to the my
init program, it displays the messsages:

"SIGNAL SIGTSTP caught"
"SIGNAL SIGCONT caught"

on the system console. On the other hand if i issue a SIGINT to the
process, the message printed on the screen is:

INTERRUPT
Kernel Panic: Attempted to kill init

It does not print the message "SIGNAL SIGINT caught" at all. This is
what drives me to the conclusion that it is not invoking my handler
function at all. What could attribute to such behaviour where my other
handler functions are properly installed and certain handlers are not
installed properly.

I even tried the below:

-----
/* log_msg is my function which prints the messages on the console */
/* Idea borrowed from SysV init */
if(signal(SIGINT, sigint_handler) == SIG_ERR) {
log_msg(L_CO,"Cant Install Handler for SIGINT");

}
------

The message was never printed when init was booting up. This is right at
the begining of the program, so i can clearly observe it.

TIA

Karthik