Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Fedora 12 gcc 4.4.1

I am doing some programming, and my program gave me a stack dump.

However, there is no core file for me to examine.

So I did:

ulimit -c unlimited

and got this error message:

bash: ulimit: core file size: cannot modify limit: Operation not permitted

I also tried setting ulimit to 50000 and still got the same error.

The results of ulimit -a:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 12275
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
share|improve this question
up vote 17 down vote accepted

Grep for a hard limit setting in your bash initialization files. From the bash man page.

A hard limit cannot be increased once it is set; a soft limit may be increased up to the value of the hard limit.

The hard limit is set via the ulimit -H flag. It may be set in /etc/bash* or /etc/profile* files. Look for a ulimit -Hc setting.

share|improve this answer

This is obviously a bit late, but for anyone else who stumbles across this page, I found this link had all the answers I needed:

share|improve this answer

I had this happen to me when I used dropbear as an SSH server. Apparently, dropbear sets some hard limits before spawning your shell.

Switching to OpenSSH solved the problem.

share|improve this answer
Indeed. Right in the start of main() there's a call to disallow_core(), which calls setrlimit(2). For security reasons of course, but there must be a better way. – Sundae May 6 '15 at 6:10

sudo ulimit fails because ulimit is a built-in and sudo takes an executable as the first argument which it will search in PATH. sudo cd / fails for the same reason.

A workaround is to do:

 sudo sh -c "ulimit -c unlimited && exec su $LOGNAME"
 ulimit -c


share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .