>That may be so, but why does the lame Linux kernel silently ignore >the kill() call instead of properly returning an error. > > Wietse
:) I don't write the code, just reporting the bad news! I think however the reasoning is as follows: clearly a user-mode process can send a signal to init to force it to re-read its config, etc. At the time that said process generates the signal with the kill system call, it could be masked. It isn't until the signal is actually delivered to pid 1 that the kernel, acting in the context of pid 1, realizes that the signal is now unmasked and the signal's disposition is set to SIG_DFL which will cause process termination. At that point, the signal is silently discarded. /usr/src/linux/kernel/signal.c:3646 or thereabouts depending on kernel version. Signal generation and signal delivery are asynchronous of each other so a condition discovered during signal delivery can not be reported back as an error code to a system call. I can see your point that at the time the user-mode process tries to send the signal to pid 1, if that signal is unmasked and is SIG_DFL, then the kill system call could fail synchronously maybe with EINVAL or EPERM.
