NGINX: connect() to unix:/var/run/php7.0-fpm.sock failed (2: No such file or directory)
I’m trying to follow this Ansible tutorial while adjusting it for Ubuntu 16.04 with php7. Below this message you’ll find my Ansible file. After running it and trying to visit the page in the browser I get a 404, and the following in the nginx error logs:
2016/10/15 13:13:20 [crit] 28771#28771: *7 connect() to unix:/var/run/php7.0-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 93.xxx.xxx.xx, server: 95.xx.xx.xx, request: «GET / HTTP/1.1», upstream: «fastcgi://unix:/var/run/php7.0-fpm.sock:», host: «95.xx.xx.xx»
$ sudo ls -l /var/run/php total 4 -rw-r--r-- 1 root root 5 Oct 15 13:00 php7.0-fpm.pid srw-rw---- 1 www-data www-data 0 Oct 15 13:00 php7.0-fpm.sock $ sudo ls -l /var/run/php7 ls: cannot access '/var/run/php7': No such file or directory $ sudo ls -l /var/run/php7.0-fpm.sock ls: cannot access '/var/run/php7.0-fpm.sock': No such file or directory Why can ls find the socket file if I search it by part of the name php while it cannot find the socket file when I list more than that php7 or even the full name php7.0-fpm.sock ? And most importantly, how can I make this work with nginx? All tips are welcome! below I pasted my Ansible file
--- - hosts: php become: true tasks: - name: install packages apt: name=> update_cache=yes state=latest with_items: - git - mcrypt - nginx - php-cli - php-curl - php-fpm - php-intl - php-json - php-mcrypt - php-mbstring - php-sqlite3 - php-xml - sqlite3 - name: enable mbstring shell: phpenmod mbstring notify: - restart php7.0-fpm - restart nginx - name: create /var/www/ directory file: dest=/var/www/ state=directory owner=www-data group=www-data mode=0700 - name: Clone git repository git: > dest=/var/www/laravel repo=https://github.com/laravel/laravel.git update=no become: true become_user: www-data register: cloned - name: install composer shell: curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer args: creates: /usr/local/bin/composer - name: composer create-project composer: command=create-project working_dir=/var/www/laravel optimize_autoloader=no become: true become_user: www-data when: cloned|changed - name: set APP_DEBUG=false lineinfile: dest=/var/www/laravel/.env regexp='^APP_DEBUG=' line=APP_DEBUG=false - name: set APP_ENV=production lineinfile: dest=/var/www/laravel/.env regexp='^APP_ENV=' line=APP_ENV=production - name: Configure nginx template: src=nginx.conf dest=/etc/nginx/sites-available/default notify: - restart php5-fpm - restart nginx handlers: - name: restart php7.0-fpm service: name=php7.0-fpm state=restarted - name: restart nginx service: name=nginx state=restarted - name: reload nginx service: name=nginx state=reloaded /usr/bin/env: php: No such file or directory
So this seems to me as very specific case, why this command does not work. I spent 12 hours of debugging it and I am out of ideas here.
P.S.: Similar error ( /usr/bin/env: node: No such file or directory ) occurs when there is bower install (using Bower), but not when running npm install (using NPM).
Run sh deploy instead of bash deploy (maybe some bashism). How did you check the «following things«? I recommend to check them in the script, so that you can discover eventual overrides and sanitations of envs.
regarding «following things«: I added them to start of deploy.sh script and they output these things I put down to question. Same output is when I run them alone, though.
Show that line here, please. I recommend you to replace your php command at this line in your script with output to file to examine environment variables at the moment of calling /usr/bin/env: /usr/bin/env > environment.txt
6 Answers 6
Make sure that line endings and/or invisible spaces aren’t causing the problem.
Remove the spaces in the first line of the script and insert new ones, making sure not to hold CTRL while pressing space.
I am using IDE, which automatically checks (and converts) CR+LF to LF only, removes BOM and cares about white characters, but I double-checked it, and it appears ok (still not working though). Thanks anyway
The env command will look through a user’s $PATH to find the first executable of the given name. So, /usr/bin/env php will look for an executable file called php in any of the directories in the $PATH of the user running it.
In your case, that’s almost certainly because when running a command over ssh , you don’t start a full shell and don’t actually read your shell’s initialization files. You can check this by running this command (note the single quotes):
ssh deployer@XXX.com 'echo $PATH' And comparing the output to what you get if you ssh deployer@XXX.com and then run echo $PATH . On my system. for example:
$ echo $PATH /usr/bin:/usr/local/sbin:/usr/local/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl: $ ssh localhost 'echo $PATH' /usr/bin:/bin:/usr/sbin:/sbin Therefore, the $PATH that your script has access to when run with ssh deployer@XXX.com is not the same as when you log in to test it.
In any case, the simple solution is to use the full path to the interpreter instead of env . Both env and full paths have their benefits and drawbacks but, in this case, the path is safer:
I am actually using full paths everywhere, as I mentioned in my question, the error is reported inside composer install command, which i obviously cannot modify. Also $PATH is ok, as I mentioned in my question too, I checked all the things by adding them into the script and running remotely via ssh login. Also I can not check the ssh deployer@XXX.com ‘echo $PATH’ as you stated, since my ssh login is limited to one script only, but I hovever did check it when I add $PATH to that script (stated above) Anyway, thank you for your answer, and accept +1 for explaining me the env thing
@TomášBlatný well, you’re using env somewhere, or you wouldn’t be seeing that error. I don’t know composer but you will probably have to copy or link the php executable to a directory in its path. This sort of thing is hard to debug since there are so many things each depending on the other.
Thats true, env is actually called inside composer. But this does not solve the problem, why some composer calls pass, and some not. However I will futher investigate this by looking into its code. Thanks for your time
@TomášBlatný I am guessing that those that pass are calling binaries that are in a directory that is in whatever limited PATH composer uses. Try linking the ones that don’t work into the directory holding the ones that do. Good luck!
Easiest way. change the user’s shell as the script.
/etc/passwd
Before: deploy:x:0:0. /root:/bin/bash After: deploy:x:0:0. /root:/scripts/deploy.sh Example script (make sure execute bit is set chmod +x)
/scripts/deploy.sh
#!/bin/bash PATH=$PATH:/moo etc. moo.sh 
Works everytime! You should even be able to use the script to troubleshoot/debug any env variables which you may feel are unset etc . also the handling arguments being passed into ssh will work as well..
Note: Its Best Practice to always FULLY QUALIFY the paths for any scripts, executables, etc.. Above is just an example which allows the default path to be set to call moo.sh within the moo folder 😉
That was easy.. Thanks for posting..
Nice answer, but I actually never use the user on server directly, I always ssh to server, and by lane in authorized_keys , the script gets called and then connection ends. How shall I modify authorized_keys to keep this working?
It should work the same. You would be authenticating via key and as long as the shell is set to the script for the remote account in question within the remote server’s /etc/passwd file the script will execute. I’ll add a screenshot to my post shortly.
Thanks for your answer, it did not solve my problem, but was for me the most interesting and actually solved other problems I had. Gave you the bounty, thanks again
Is it possible that bash needs a reset to its hash table?
If so, you might try adding hash -r somewhere in your script, which forces the shell to look through $PATH again rather than relying on (possibly outdated) info from the hash table.
When needed, hash can also enable the shell to remember paths to executables installed in non-standard locations using the -p option, or forget paths with the -d option.
Looks like maybe you need to add php to your path. Try:
vim ~/.bashrc PATH=$PATH:/usr/local/bin/php export PATH You might also want to check where your php lives to be sure that the path there is correct. Try:
Well this is not the problem, since php -v outputs correct PHP version and composer —version outputs composer version. As I said, problem is in one command only.
It is clear that you have a path problem since your deploy script can’t find things that are definitely on the path when you do a normal ssh login.
First thing to do to confirm you have a PATH issue is to update your deploy script to log the output of env or at least echo $PATH . I am guessing that the way your deploy script is called, $PATH is not set as you would expect. This debug output will confirm/deny my theory.
I looked at the tutorial you followed. You should probably make sure at update the command= to be command=»/bin/sh /path/to/your/script. » if you haven’t already to make sure your script is run by the right shell.
If you do have a PATH problem, a quick/dirty fix is just to explicitly set PATH at the beginning of your deploy script.
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" Detailed explanation and further options.
On linux when commands are run they inherit the environment of their parent process.
When you login as a normal user via SSH there are things that happen (like running /etc/bashrc /etc/profile ~/.bash_profile ~/.bashrc etc). At that point you have may have updated your process’s environment by doing things like export PATH=»$PATH:~/mybin» in those scripts. Now any future processes that you run will inherit your current environment.
Running a command instead of getting a login shell means that command is run by the ssh daemon and will inherit the environment of the ssh daemon process. which is likely different than your environment as a logged in user.
The man page for authorized keys covers what happens after authentication. Regarding environment:
- Reads the file ~/.ssh/environment, if it exists, and users are allowed to change their environment. See the PermitUserEnvironment option in sshd_config(5).
So the appropriate place to configure environment for the process is in ~/.ssh/environment where ~ is the home directory for the user that is authenticated to run the command. You also need to check your sshd_config to make sure PermitUserEnvironment is allowed.
~/.ssh/environment format is also specified in the man page of course.
This file is read into the environment at login (if it exists). It can only contain empty lines, comment lines (that start with '#'), and assignment lines of the form name=value. The file should be writable only by the user; it need not be readable by directory becomes accessible. This file should be writable only by the user, and need not be readable by anyone else. An alternative way to specify the environment without using the above mentioned method is to use the environment=»NAME=value» option in the authorized_keys file. See the man page I linked above for details.