Re: RLIMIT_CORE set to 0

From: MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
Date: Wed, 25 Mar 2015 14:47:47 -0400
Message-ID: <CAAaXtLC4Vcjtvo7j8jErQBkNZk_rFfSuQnj3TJQdpdNHmFkrqw_at_mail.gmail.com>



Exactly.

Each process will inherit its resource limits from its parent, but nothing stops it from then *reducing* those limits of its own accord.

On Wed, Mar 25, 2015 at 2:42 PM, Phil Jones <phil_at_phillip.im> wrote:

> Hi,
>
> Check the source code for the process itself and make sure it hasn't
> called setrlimit() - that overrides the shell setting.
>
> Cheers,
>
> Phil
>
>
>
> On 25 Mar 2015, at 18:09, msanjeevk <sanjeevorcle_at_gmail.com> wrote:
>
>
> Oracle Linux Server release 6.2
> Linux my_hostname 2.6.32-300.3.1.el6uek.x86_64 #1 SMP Fri Dec 9 18:57:35
> EST 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> We have custom software (non-oracle) being used to manage our imaging
> system.When process crashes core dump was not getting generated. I've asked
> our unix admin to make coredump value unlimited for the userid that is
> running server process, log out and relogin and double checked with ulimit
> command and it showed:
>
> ulimit -a
> *core file size (blocks, -c) unlimited*
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (blocks, -f) unlimited
> pending signals (-i) 128505
> max locked memory (kbytes, -l) 64
> max memory size (kbytes, -m) unlimited
> open files (-n) 1024
> pipe size (512 bytes, -p) 8
> POSIX message queues (bytes, -q) 819200
> real-time priority (-r) 0
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) 1024
> virtual memory (kbytes, -v) unlimited
> file locks (-x) unlimited
>
> From same shell prompt started process and it still did not generate core
> dumps on the subsequent crash has following message in logfile:
> Process 2504(cumulusd) has RLIMIT_CORE set to 0
> Aborting core
>
> wondering what iam missing here.
>
> Regards,
> Sanjeev.
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Mar 25 2015 - 19:47:47 CET

Original text of this message