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: Lionel Cons
Subject: Re: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded
Date: Tue, 16 Jul 2013 22:31:25 +0200

On 15 July 2013 15:35, Chet Ramey <address@hidden> wrote:
> On 7/14/13 2:38 PM, Cedric Blancher wrote:
>> The tests below is from the ongoing work of David Korn and Roland
>> Mainz to make signals in ksh93 reliable and predictable (so far no
>> shell tested really does it). I derived one of their tests and found
>> that bash doesn't handle realtime signals properly either:
>> bash -c '{ trap ":" RTMIN ; kill -STOP ${BASHPID} ; true ; } & ((
>> pid=$! )) ; sleep 5 ; maxi=$(ulimit -i) ; for ((i=0 ; i < (maxi*2) ;
>> i++)) ; do kill -RTMIN $pid ; done ; kill -CONT $pid ; wait ; true'
>> This prints 1, but IMO should print $(ulimit -i) as integer value and
>> then lots of errors from kill(1) because no further signals can be
>> queued to $pid because ulimit -i is exceeded for that child process.
>
> Two things: First, the script as supplied doesn't print anything.

Any idea why there is this difference?

> Second,
> the kill system call never returns < 0, so the kill builtin won't print
> an error message.
>
> I took your script, added a little debugging code to bash, and ran it.
> It sent 63000+ signals to the stopped process without kill(2) ever
> returning an error.

Either your ulimit -i is greater than 63000 or we have a Linux bug. If
ulimit -i is reached then kill(1) should fail.

Lionel



reply via email to

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