06 Oct, 2008, Zeno wrote in the 2nd comment:
I would suggest allowing your user to use ulimit -c, although I don't know how. By default users were able to for me on my Slackware server.
06 Oct, 2008, quixadhal wrote in the 3rd comment:
You might also need to poke through the .bashrc, .bash_profile, and all those shell startup files… including any in /etc that get run. ulimit is a feature of the shell, so if a system .bashrc re-limits you, your pam settings won't matter (at least in a practical sense).
10 Oct, 2008, Kline wrote in the 4th comment:
I don't see it being re-limited anyplace like the different startups or bash profiles. I've also added a ulimit -c unlimited to my system-wide and local user .bashrc files. It still says operation denied, even when run from there. How do you "allow a user" to use ulimit?
11 Oct, 2008, quixadhal wrote in the 5th comment:
All I can say for sure is that a non-root user can't increase their limit above its current value. So, if you have a limit of 16M for coresize, something is setting that limit, or your version of bash has that as a compiled-in default. So, somewhere, something is imposing that limit before your shell switches to your non-root UID.
It looks like pam_limits is a module. Hopefully it's smart enough to re-read the config file?
It looks like pam_limits is a module. Hopefully it's smart enough to re-read the config file?
Random Picks
My user account on my machine is limited to 16mb cores. I need to increase this. ulimit -c says denied. Ok, cool. I su to root, edit /etc/security/limits.conf and set myself up for unlimited soft and hard limits. I re-login (it's per login, right?), ulimit -a shows no change, and I'm still denied to ulimit -c. My /etc/pam.d/common-session has session required pam_limits.so, too.
Where have I gone wrong? :(