[Top][All Lists]

[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: Chet Ramey
Subject: Re: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded
Date: Mon, 15 Jul 2013 09:35:49 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

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. 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.

(RHEL 5, bash-4.3-beta)

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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