Yes, all lines of /etc/security/limits.conf are commented out and session ulimit -a indicates the defaults are being used:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 385725
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) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 385725
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) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
On Thu, Dec 11, 2014 at 5:19 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
On Thu, Dec 11, 2014 at 12:05 PM, Carlos Henrique Reimer
<carlos.reimer@xxxxxxxxxxxxx> wrote:
> That was exactly what the process was doing and the out of memory error
> happened while one of the merges to set 1 was being executed.
You sure you don't have a ulimit getting in the way?
--
