Re: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded

[Linus Torvalds]

On Tue, Jul 16, 2013 at 1:31 PM, Lionel Cons <lionelcons1972@gmail.com> wrote:
>
> Either your ulimit -i is greater than 63000 or we have a Linux bug. If
> ulimit -i is reached then kill(1) should fail.

Traditionally kill() has never returned errors for things like this.
In fact, quite arguably POSIX actively disallows kill() from returning
errors for queue overflow: "The kill() function is successful if the
process has permission to send sig to any of the processes specified
by pid. If kill() fails, no signal shall be sent."

Notice how "is successful" is not dependent on whether a signal was
sent or not, it is dependent on whether you have _permission_ to send
the signal to the specified process.

Now, I don't think "POSIX requires" is all that big a deal, and
there's a lot of gray areas where POSIX just doesn't talk about
everything that could go wrong. So I don't think the above is a very
strong argument for not possibly changing semantics, but I do argue
that it's an argument for what traditional behavior is.

I think you could quite validly argue for changing the Linux kernel
semantics, but it has to come from that direction: talk about why you
need it, show that it doesn't break other applications, maybe study
what different versions of Unix actually do or don't do wrt this. But
for Linux you'd need to do it on the kernel mailing list and probably
particularly with the people involved in the whole signal semantics
(Oleg Nesterov, Al Viro, Andrew Morton,  with me probably cc'd). And
if you have a patch, that obviously would be a great addition to that
discussion too.

                    Linus