• Sales: 1-800-961-2888
  • Support: 1-800-961-4454

Feedback

Let us know what you think of our Knowledge Center!

Open Cloud Community

Learn about Rackspace products, ask questions, and share your knowledge in our Open Cloud Community.

Installing NGINX and PHP-FPM - Setup for PHP-FPM

  • Article ID: 1320
  • Last updated on February 13, 2013
  • Authored by: Kevin Carter
  • (11 Comments)

Here you are going to simply add some POOL information to the PHP-FPM setup that you have already done. Unknowingly when you entered the command to install PHP-FPM, the system setup a default configuration for PHP-FPM. So most of the heavy lifting has been done for you.

You may have to do one thing and that is to create a directory where you want your Sockets to live while they are alive. I placed them here: /var/run/php5-fpm/ You can use this command to create the directory.

 

mkdir -p /var/run/php5-fpm/

This directory may already exists by simply installing PHP-FPM. This is the place where your file sockets will exist when online. Once you are sure that this directory exists there is nothing further you will need to do with this directory. Sockets will automatically spawn here provided you are using the virtualhost setup and PHP-FPM pool template provided.

 

 

To complete the setup move to the directory /etc/php5/fpm/pool.d/. It is here that you will setup the different UNIX Sockets that PHP-FPM will function on. 

 

Please Note:  In order for your system to function properly you will need to create a new POOL for every Virtual Host that you had setup.

The pool files should follow this naming convention: YOURDOMAIN.conf

Here is a template for the pool files.

[DOMAINNAME]

listen = /var/run/php5-fpm/DOMAINNAME.socket
listen.backlog = -1

; Unix user/group of processes
user = (THE USERNAME OF THE USER THAT OWNS THE SITE FILES)
group = www-data

; Choose how the process manager will control the number of child processes.
pm = dynamic
pm.max_children = 75
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; Pass environment variables
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

; host-specific php ini settings here
; php_admin_value[open_basedir] = /var/www/DOMAINNAME/htdocs:/tmp

Please remember to replace all instances of "DOMAINNAME" with then name of your domain.

 



© 2011-2013 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER

11 Comments

You can also just set the listen socket like this:

listen = /var/run/php5-fpm/$pool.socket

Makes it a bit easier to copy configs around.
By Anonymous on Jul. 30, 2012

This article is great. I recently decided to give Rackspace (and nginx) a shot and began moving a couple of my domains over from my old VPS. I used this article to set things up, added some more configuration for Drupal, and everything is working well except for one thing.

Drupal is working great for everything EXCEPT using php to generate images using Drupal image styles. I get a "Error generating image." in the browser, and in the nginx logs (I set the error_log directive to debug for this) I'm seeing that it's doing the correct rewrite but then a 500 Internal Server Error happens. I checked folder permissions, and they seem fine. I can't figure it out. Any thoughts?
By Justin on Dec. 25, 2012

Glad to hear you found the article useful, Justin. The 500 error means the error is coming from Drupal or PHP-FPM, so the nginx side of things should be running fine. Searching on this issue I mostly see it occurring for people when permissions on the folder aren't allowing image creation (which it seems you've checked) or when a necessary library is missing (like the GD library), preventing the generation.

Unfortunately 500 errors are pretty generic, so it's hard to tell what the problem could be at a glance. You might check on Drupal-specific forums, as you might find more people who are familiar with the image generation functionality there.
By jered.heeschen on Dec. 26, 2012

Thanks, Jered. I actually figured it out. Since it was a new server and my first time using nginx, I figured the problem had to be something with my configuration, but that wasn't the case. It was actually so simple that I overlooked it.

I used git to clone my project from my old server to the new one. I have .gitignore set up to ignore sites/*/files, so the files in there didn't get copied, and when Drupal tried to manipulate an image within there, the image didn't exist. It's odd to me that Drupal doesn't log a more specific error for this situation, but oh well, I finally figured it out. A quick scp of the files from my old server to the new one and everything is looking good. And uploading a new image to test styles shows that they're working.
By Justin on Dec. 28, 2012

I also think it should be noted that the above values for pm.max_children, pm.start_servers, etc should be adjusted according to how much memory is on the machine and how many sites are being hosted. At first, I had the above settings for several domains on one 512MB server, but the PHP processes quickly ate up all the memory and caused all the sites to slow down dramatically. I've adjusted the values based on various guidelines I found through a google search, and everything is running great now!

Thanks for the help.
By Justin on Dec. 28, 2012

Thanks for posting your follow-ups, Justin. From what I can tell there's a long-standing bug causing the missing files to be reported as a 500 error instead of a 404 in that module. Hopefully it will get fixed before too much longer.

And thanks for the note about tuning the worker values based on your expected load and environment. It's definitely good advice - both to make sure your server can keep up with normal traffic, and to keep it from overloading the system and grinding to a halt if you get an unexpected traffic spike.
By jered.heeschen on Dec. 28, 2012

ok, I have been attempting to get this going for a bit now, after hours of looking around and checking things, I think I need a little help or guidance.
First I don't have any of this on the web yet. I am running it from an extra computer in my home to test.

I have managed to get Nginx working using a simple vhost file and an index.html file. so the issue is with fastcgi and the socket I believe.

I created the directory:
mkdir -p /var/run/php5-fpm/

and set ownership:
sudo chown -R www-data:www-data /var/www/jieiku.com

the computer I am using to access my ubuntu machine has the hosts file edited to point to the local IP address when going to jieiku.com or www.jieiku.com

After a reboot the /var/run/php5-fpm/ folder is gone.

my pool config file is named "jieiku.com.conf" and I have it set:
user = www-data
group = www-data

So I am all the way to the end of the guide when I try to access my page, I get 502 Bad Gateway with a horizontal line and then nginx/1.2.1 at the bottom of the page.

I checked the log and when I try to access www.jieiku.com/index.php it shows:

2013/02/02 20:27:02 [crit] 1798#0: *1 connect() to unix:/var/run/php5-fpm/jieiku.com.socket failed (2: No such file or directory) while connecting to upstream, client: 192.168.1.100, server: jieiku.com, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm/jieiku.com.socket:", host: "jieiku.com"

any help greatly appreciated :)
By Jake on Feb. 2, 2013

The /var/run/php5-fpm directory is the mostly likely culprit - if the directory isn't there, then the socket file can't be created. Try creating the directory without the "-p" option, to see if you get any error that way. You might also try chowning that directory over to www-data.

If the directory is only disappearing after a reboot then there may be a system process cleaning the /var/run directory out. As an experiment you might try using another directory to hold the socket file (maybe in /etc/php/fpm/run) to see if the issue is specific to /var/run.
By jered.heeschen on Feb. 3, 2013

/var/run is typically a tmpfs partition so will always be reset on reboot.

I'm trying to work on the best way to fix this at the moment too. I noticed that many other daemon processes simply make their init script check that /var/run/XYZ is already there or create it, for example mysql does this:

[ -d /var/run/mysqld ] || install -m 755 -o mysql -g root -d /var/run/mysqld
By Robbie Mackay on Mar. 12, 2013

Ended up adding this to /etc/init.d/php5-fpm

SOCKETDIR = /var/run/php5-fpm

then under do_start()

[ -d $SOCKETDIR ] || install -m 755 -o www-data -g root -d $SOCKETDIR
By Robbie Mackay on Mar. 12, 2013

Thanks Robbie. Quite correct, and I appreciate the correction. Still, you should be able to create the directory then attempt to start the service again to see if that fixes the issue (without a reboot in-between). If it doesn't, then you know to look elsewhere.

The error message complains about not being able to connect to the socket being created by php-fpm. That could mean something as simple as it trying to create that file and failing due to permissions or a missing directory, or it could mean there's another configuration problem or bug preventing the process from logging that it couldn't create the network socket. I don't know the inner workings of nginx/php-fpm well enough myself to say which program is responsible for creating that network socket, but I'll see if I can find out.
By jered.heeschen on Mar. 12, 2013

Add new comment