11 May, 2009, Banner wrote in the 1st comment:
Votes: 0
How do you enable core files on Debian? I tried various "fixes" that involved editing pam.d and the limits.conf, but nothing I did let a user change the ulimit. I'd like to give my user accounts unlimited core dumps, so any fix that would acheive that would be nice.

Also, I tried sticking ulimit -c unlimted in my .profile and it gave me this error:

-bash: ulimit: core file size: cannot modify limit: Operation not permitted
shoie13@swgi:~$ 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) 38912
max locked memory (kbytes, -l) 32
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) 38912
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
shoie13@swgi:~$
11 May, 2009, quixadhal wrote in the 2nd comment:
Votes: 0
You can't raise (or lower) a limit above (or below) that which is set by the system unless you have root privs. If your system administrator has set your core size to 0 (disabling core dumps), you'd need to get them to change it. That's why you're getting the Operation not permitted error.

If you ARE the sys admin, you need to figure out which of the 500 bazillion places the abomination that is GNU + a random linux distribution is setting it in, and stop it from happening. :)

It could be in any of the bash system config files, or it could also be a setting in something else (like the pam login system) which gets done before your shell is launched.
11 May, 2009, Banner wrote in the 3rd comment:
Votes: 0
I have root priveleges, I just want to know where to go to make it so.
11 May, 2009, David Haley wrote in the 4th comment:
Votes: 0
I would suggest searching on Ubuntu forums for most of this stuff, since generally Ubuntu works like Debian. The exact location will probably be in there somewhere. I don't know it off the top of my head but it'll most likely be in /etc somewhere.
13 May, 2009, Banner wrote in the 5th comment:
Votes: 0
If anyone else needs the help, I figured it out. in /etc/security/limits.conf, add these lines:

#*               soft    core            0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#ftp - chroot /ftp
#@student - maxlogins 4
* soft core 0 #This line
* hard core unlimited #This line


Google was no help this time, unfortunately, had to tweak to get it to work.
13 May, 2009, quixadhal wrote in the 6th comment:
Votes: 0
Ah, yep… my debian system also uses this file layout, although the default here is everything commented out, and thus no limits beyond what was compiled in. soft 0 and hard unlimited sounds good, as the default would not leave a core but you could override it when you wanted one.
13 May, 2009, Banner wrote in the 7th comment:
Votes: 0
Well, it's a vps with just me and Igabod on it, so as long as neither of our MUDs fill up all the hdd with huge core files we should be good leaving it at unlimited, although all the websites I looked at for enabling core dumps suggested leaving it off on a production server, I hope that's no problem with a MUD server.
13 May, 2009, David Haley wrote in the 8th comment:
Votes: 0
Thanks for sharing the config file, Banner. It's a question that comes up from time to time so hopefully others will find it useful in the future.
13 May, 2009, Banner wrote in the 9th comment:
Votes: 0
David Haley said:
Thanks for sharing the config file, Banner. It's a question that comes up from time to time so hopefully others will find it useful in the future.

I hope it's useful. You're welcome.
15 Jun, 2009, Banner wrote in the 10th comment:
Votes: 0
*casts revive old post*

Anyway, I rebooted the server (and at some point was moved from one server to another (due to a problem on the rack server I was on, I'm still with Quantact), but I noticed that ulimit was no longer working. It appears that most of the settings are in the same place but its no longer allowing me to enable cores for my user, only root. I've posted on Debian forums, the hosting provider forums, Ubuntu forums, and no one seems to know how to fix it, and the hosting provider even said it probably doesn't work at the vm level, which I know isn't true because it was working at some point beforehand. So once again, if -anyone- knows -anything- I can try to make core dumps happen, please share. :)
15 Jun, 2009, David Haley wrote in the 11th comment:
Votes: 0
Well, I'm not sure how to fix it, but I'm pretty sure that your hosting provider is wrong about the VM preventing it. I guess that counts as knowing "something", but unfortunately not a very useful something. :wink:

When you just display the limits (by typing just ulimit, I think? or maybe it's limit -a… don't have to deal with this enough to remember for sure) what comes up?
15 Jun, 2009, Banner wrote in the 12th comment:
Votes: 0
-bash: ulimit: core file size: cannot modify limit: Operation not permitted
shoie13@swgi:~$ 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) 71680
max locked memory (kbytes, -l) 32
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) 71680
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
shoie13@swgi:~$
15 Jun, 2009, David Haley wrote in the 13th comment:
Votes: 0
So you are sure that the config files are correct, and that you have rebooted since the config files were correct? Could you paste the relevant config file here against just for good measure?

So the only changes were:
- your VM was shut down
- it was moved to another physical server
- you restarted it

You didn't have anything like kernel upgrades, distribution upgrades, etc.?
15 Jun, 2009, Banner wrote in the 14th comment:
Votes: 0
David Haley said:
So you are sure that the config files are correct, and that you have rebooted since the config files were correct? Could you paste the relevant config file here against just for good measure?

So the only changes were:
- your VM was shut down
- it was moved to another physical server
- you restarted it

You didn't have anything like kernel upgrades, distribution upgrades, etc.?



/etc/security/limits.conf:

[snip]
#<domain> <type> <item> <value>
#

#* soft core 0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#ftp - chroot /ftp
#@student - maxlogins 4
* soft core 1000000
* hard core unlimited

# End of file

appAdmin soft nofile 8000
appAdmin hard nofile 8000


/etc/pam.d/ssh

[snip]
# Print the message of the day upon successful login.
session optional pam_motd.so # [1]

# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so


/etc/pam.d/login

[snip]

# set access limits.
# (Replaces /etc/login.access file)
# account required pam_access.so

# Sets up user limits according to /etc/security/limits.conf
# (Replaces the use of /etc/limits in old login)
session required pam_limits.so



I didn't do kernel upgrades, I'm using OpenVZ, but I did update twice or so since then. I do believe there were some changes I did to /etc/security/pam_env.conf, but everything in there is commented out and I can't find the link I used that mentioned that file, so perhaps therein lies the problem?

Edit to add: The changes I mentioned to pam_env.conf were back when the core dumps initially started working, not afterwards.
15 Jun, 2009, David Haley wrote in the 15th comment:
Votes: 0
What about /etc/limits?

And what if you disable limits entirely by not loading pam_limits.so? (not sure that'll do anything, but it's worth a shot, at least to get started on debugging this)
15 Jun, 2009, Banner wrote in the 16th comment:
Votes: 0
David Haley said:
What about /etc/limits?

And what if you disable limits entirely by not loading pam_limits.so? (not sure that'll do anything, but it's worth a shot, at least to get started on debugging this)


/etc/limits does not exist/is a new file. Will disabling limits allow anything to be set, and I assume a reboot is necessary?
15 Jun, 2009, David Haley wrote in the 17th comment:
Votes: 0
Banner said:
Will disabling limits allow anything to be set

I'm not sure I understand exactly what you mean, but I think it will simply disable restrictions on things like core limit size, CPU usage, etc.

Banner said:
and I assume a reboot is necessary?

Might be, but at the least you'll have to log out and back in.
15 Jun, 2009, Runter wrote in the 18th comment:
Votes: 0
Little off topic, but does anyone know how to make the cores in linux default with an index number? I've seen some systems I've worked on in the past doing that.
15 Jun, 2009, David Haley wrote in the 19th comment:
Votes: 0
I've seen them tagged with the process id, not an index number, although to be honest I don't know how to configure that.
15 Jun, 2009, Runter wrote in the 20th comment:
Votes: 0
David Haley said:
I've seen them tagged with the process id, not an index number, although to be honest I don't know how to configure that.


That's probably what I'm thinking of actually.
0.0/42