that’s whacked

thoughts on open spaces

Quick links: content, navigation, search.

Navigation

php5 “Unable to fork” on Solaris

Thursday, Dec 6. 2007 – Category: Grommit, OpenSolaris

I was battling with inconsistent behaviour for grommit with PHP5 periodically (50% of the time, roughly) throwing the dreaded “Unable to fork” error (seen on both exec() & passthru() calls). Googling for it gives tons of great info for what causes this problem on Windows; but virtually none on Solaris.

Finally after some truss and DTrace-fu, I saw what was happening. exec() was calling open(), and since httpd is a 32 bit process, it was hitting the 256 file descriptor limit.

Booooooo.

A quick modification to /lib/svc/method/http-apache2 to do a:

ulimit -n 65535 LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 export LD_PRELOAD_32

before the line calling apachectl at the end fixed the problem for me.

Seems like other people should have hit this problem though; which makes me curious why I don’t see any other hits on Google about it.

No Trackbacks to “php5 “Unable to fork” on Solaris”

9 Comments to “php5 “Unable to fork” on Solaris”

Darren Moffat Says:
December 6th, 2007 at 11:21
It it wasn’t for the ulimit you could have done this in the much more supported (and not going to get blown away on upgrade) way of setting the environment variable using svccfg.
Stephen Lau Says:
December 6th, 2007 at 11:38
Yeah – I looked at trying to do it with smf properties and svccfg – but couldn’t figure out how because of the ulimit.
Geoff Arnold Says:
December 6th, 2007 at 12:02
So is this the explanation for WordPress not consistently sending email notifications of blog events?
heavygirl Says:
December 6th, 2007 at 12:35
Ugh, 256 default FD limit in a multithreaded, “modern” and “advanced” OS in 2007. Isn’t this silly?
Stephen Lau Says:
December 6th, 2007 at 13:21
@Geoff: It could be, yeah. Depends if WordPress was trying to do it all within PHP using sockets & SMTP, or if it was making an exec() call to /usr/lib/sendmail.

@heavygirl: Nope, don’t blame Solaris. Blame POSIX.
richlowe Says:
December 6th, 2007 at 14:16
the standards define FILE to be opaque, posix shouldn’t care.

I seem to recall the issue is that FILE would change size on applications.

(I also vaguely recall this only being an issue for the 32bit ISAs?)
Chris Josephes Says:
December 6th, 2007 at 16:12
I saw this issue a lot. I worked at a place that served webpages that literally had 200+ server side includes, and opened dozens of logfiles. Back then the only solution was to upgrade to 64 bit.
Stephen Lau Says:
December 6th, 2007 at 16:19
Sadly /usr/apache2/bin/apachectl and httpd are delivered as 32-bit only.
Vladimir Kotal Says:
January 2nd, 2008 at 03:05
upgrade to latest Nevada, it has 64-bit apache in:

http://blogs.sun.com/jyrivirkki/entry/apache2256is

http://opensolaris.org/os/community/arc/caselog/2007/586/