Live data from Hacker News

Don't Leave Coredumps on Web Servers

blog.hboeck.de

11–20 of 34 posts

Re: Don't Leave Coredumps on Web Servers

#11
post #10

"PHP used to crash relatively often." ? In 15 years of hosting hundreds of PHP site, I've never seen a single coredump. Is it just me ?

No OS I've used in the last ~10 years left a core dump by default. Maybe longer, but I didn't know what core dumps were then, so I wouldn't know what I was looking at if they did.

Re: Don't Leave Coredumps on Web Servers

#12
post #10

"PHP used to crash relatively often." ? In 15 years of hosting hundreds of PHP site, I've never seen a single coredump. Is it just me ?

Do you have coredumps enabled on your hosting servers? As written in the blogpost the major distributions have a configuration that will forward coredumps to crash handling tools and not directly store them. Others simply have coredumps disabled by default.

Re: Don't Leave Coredumps on Web Servers

#14
post #10

"PHP used to crash relatively often." ? In 15 years of hosting hundreds of PHP site, I've never seen a single coredump. Is it just me ?

It's not hard to make PHP seg fault and in the course of doing web development and hosting you will need to use core files to debug opaque issues with GDB.

Re: Don't Leave Coredumps on Web Servers

#15
post #10

"PHP used to crash relatively often." ? In 15 years of hosting hundreds of PHP site, I've never seen a single coredump. Is it just me ?

It's not hard to make PHP seg fault and in the course of doing web development and hosting you will need to use core files to debug opaque issues with GDB.

I've had to do this ~3 times in the last couple years. In all cases it was extensions not playing well (xcache, gmagick/imagick). I actually couldn't find a single version of gmagick/imagick that tore down or something properly in php 7.0.x (broke when phpunit launched extra-process tests, among other places)

Re: Don't Leave Coredumps on Web Servers

#17
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.

Re: Don't Leave Coredumps on Web Servers

#18

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 w…

I 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.

Re: Don't Leave Coredumps on Web Servers

#20
post #18

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 w…

I 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 so…

>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.

Post reply on HN