bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joshuah Hurst
Subject: Re: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded
Date: Sat, 27 Jul 2013 14:48:01 +0200

On Tue, Jul 16, 2013 at 11:12 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> 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.

I think that Linux is wrong here: It should never fail if a signal
can't be send. It'll break too much stuff if that happens. Sadly,
Linux does exactly that, and it only happens when the system is under
stress, i.e. when memory is scare.

Josh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]