Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Leave Coredumps on Web Servers

blog.hboeck.de

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Don't Leave Coredumps on Web Servers

#21

Post by mpa000 »

Xoros wrote: 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 depends on how you are running it, in my experience. We're forced, due to ISP restrictions, to use FastCGI. I've not tested this theory, so YMMV, but I've had more trouble doing it that way than when using PHP as a module. We've seen less of it over the past few years, but it happened regularly enough in the past to make "grep for coredumps" a regular task.

Re: Don't Leave Coredumps on Web Servers

#22

Post by mnm1 »

Xoros wrote: 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 ?

I've experienced one or two over twelve years, usually due to a new version and always caught in dev. PHP crashes are incredibly rare.

Re: Don't Leave Coredumps on Web Servers

#23

Post by jwilk »

Terr_ wrote: post #5

If you want to test your coredump configuration for webpages (as opposed to the command-line interpreter) here's a little suicidal script for triggering it on demand: https://gist.github.com/DHager/a63d36dade21150dd86d

It's "kill -QUIT", not "kill -SIGQUIT". (But "kill -3" works too.)

Re: Don't Leave Coredumps on Web Servers

#24

Post by anamexis »

jwilk wrote: post #23
Terr_ wrote: post #5

If you want to test your coredump configuration for webpages (as opposed to the command-line interpreter) here's a little suicidal script for triggering it on demand: https://gist.github.com/DHager/a63d36dade21150dd86d

It's "kill -QUIT", not "kill -SIGQUIT". (But "kill -3" works too.)

At least for GNU, it is valid to prefix the signal specification with SIG.

cf. https://github.com/coreutils/coreutils/blob/master/src/opera...

Appears to be the case for BSD as well: https://github.com/freebsd/freebsd/blob/master/bin/kill/kill...

Re: Don't Leave Coredumps on Web Servers

#25

Post by cpantoga »

hannob wrote: post #18
cpantoga wrote: post #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 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…

Fair enough, I just wanted to point out the difference between soft and hard limits.

Re: Don't Leave Coredumps on Web Servers

#26

Post by jwilk »

anamexis wrote: post #24
jwilk wrote: post #23

Earlier quoted context omitted.

It's "kill -QUIT", not "kill -SIGQUIT". (But "kill -3" works too.)

At least for GNU, it is valid to prefix the signal specification with SIG. cf. https://github.com/coreutils/coreutils/blob/master/src/opera... Appears to be the case for BSD as well: https://github.com/freebsd/freebsd/blob/master/bin/kill/kill...

The SIG prefix doesn't work in dash (the default shell in Debian).

POSIX¹ says:

An early proposal also required symbolic signal_names to be recognized with or without the SIG prefix. Historical versions of kill have not written the SIG prefix for the -l option and have not recognized the SIG prefix on signal_names. Since neither applications portability nor ease-of-use would be improved by requiring this extension, it is no longer required.

¹ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ki...

Re: Don't Leave Coredumps on Web Servers

#27

Post by octalmage »

bpicolo wrote: post #15
tzakrajs wrote: post #14

Earlier quoted context omitted.

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)

I've always found the cause to be extensions as well. Usually a version conflict or something. It's so difficult to debug though. Always takes a while just to get everything you need to finally dig in.

Re: Don't Leave Coredumps on Web Servers

#30

Post by khedoros1 »

andreareina wrote: post #11
Xoros wrote: 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.

A bunch of the Unixes I've worked with do, it seems like. And at least some of the Linux systems on my own computers (I'm almost positive that this was my first contact with the idea of a core dump).
Post reply on HN