3 ms·
I just want to point out that the article says you should disable coredumps by putting "* soft core 0" in your limits.conf file. You should actually put "* hard
by cpantoga 9y ago
I just want to point out that the article says you should disable coredumps by putting "* soft core 0" in your limits.conf file. You should actually put "* hard core 0" in your limits.conf file. The soft limit is user configurable, meaning applications that have code which changes the ulimit for coredumps will still create coredumps. You can test this yourself by typing "ulimit -c unlimited" in your terminal -- you will not be able to create coredumps of unlimited size. Limits have a soft and hard value. The soft value is the user-configurable max. Meaning, users can reconfigure this. The hard value is the system limit, meaning if you set the hard value to 0 no user will be able to change it.
- hannob 9y agoI didn't go into the details, because, well, that was more a side aspect of the blogpost. Technically you're right. However how you're setting these things depends on your needs. Let's assume you have a server where several people develop software on. You may want to allow them to create core dumps for debugging purposes. Whether you set a hard or soft limit thus depends on your use case. I'd say usually setting a soft limit is good enough. Yes, this means users can lift the limit, however if they play with the ulimit coredump setting I assume they know what a coredump is, thus it should be okay.
- cuckcuckspruce 9y ago>Let's assume you have a server where several people develop software on. You may want to allow them to create core dumps for debugging purposes. Then set the hard core size limit for the user you're deploying as (you don't deploy as your development user, right?) and then set the soft limit for everyone else.
- cpantoga 9y agoFair enough, I just wanted to point out the difference between soft and hard limits.