>That may be so, but why does the lame Linux kernel silently ignore
>the kill() call instead of properly returning an error.
:) 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.