From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16002 invoked by alias); 16 Oct 2014 02:49:17 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33470 Received: (qmail 24921 invoked from network); 16 Oct 2014 02:49:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <141015194913.ZM13190@torch.brasslantern.com> Date: Wed, 15 Oct 2014 19:49:13 -0700 In-reply-to: <20141015223329.GV5405@sym.noone.org> Comments: In reply to Axel Beckert "Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de]" (Oct 16, 12:33am) References: <20141015223329.GV5405@sym.noone.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Axel Beckert , zsh-workers@zsh.org Subject: Re: Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de] Cc: 765410@bugs.debian.org, goswin-v-b@web.de MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 16, 12:33am, Axel Beckert wrote: } } the following has been reported in Debian at } http://bugs.debian.org/765410 and I can reprodcue it with 4.3.10, } 4.3.17, 5.0.6 and 5.0.7. } } The issue seems to only appear if ulimit is run as root user. I was } not able to reproduce it as non-root user. (I was also unable to } reproduce it on any of Debian's kfreebsd-* architectures, so it may be } a linux-only issue, too.) This is primarily a documentation issue. As root, "ulimit" by default attempts to raise both the hard and soft limits, but only lowers the soft ones. Each time you try to lower the soft limit, it attempts to re-assert the previously specified hard limit, and generates the error -- but the soft limit is in fact been correctly changed, as you can see by examining the output of the "limit" command (without the leading "u"). To lower the hard limit again and make the error message go away, one simply has to use "ulimit -H ...". This could also be fixed by having bin_ulimit read back the actual limit after a failure to set the hard limit and store that instead of keeping the "desired" hard limit around and trying to change it again.