PHP-FPM is running locally on my Ubuntu 20.04 installation, configured to listen on a socket:
/etc/php/7.4/fpm/pool.d/www.conf:
[www]
user = www-data
group = www-data
listen = /run/php/php7.4-fpm.sock
listen.owner = www-data
listen.group = www-data
;listen.mode = 0660
;listen.acl_users =
;listen.acl_groups =
I can start a Docker container and communicate with PHP-FPM by sharing the socket file through a bind mount volume:
$ docker run --rm -it \
-v "/etc/passwd:/etc/passwd:ro" \
-v "/etc/group:/etc/group:ro" \
-v "/run/php/php7.4-fpm.sock:/run/php-fpm/www.sock" \
alpine:latest
/ # apk add --no-cache fcgi
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/1) Installing fcgi (2.4.2-r0)
Executing busybox-1.31.1-r16.trigger
OK: 6 MiB in 15 packages
/ # ls -lah /run/php-fpm/www.sock
srw-rw---- 1 www-data www-data 0 Oct 30 21:25 /run/php-fpm/www.sock
/ # REQUEST_METHOD=GET SCRIPT_FILENAME=index.php cgi-fcgi -bind -connect /run/php-fpm/www.sock
Primary script unknownStatus: 404 Not Found
Content-type: text/html; charset=UTF-8
File not found.
Now if I restart PHP-FPM on the host while the container is still running:
$ sudo systemctl restart php7.4-fpm.service
$ sudo tail -n 6 /var/log/php7.4-fpm.log
[30-Oct-2020 18:25:36] NOTICE: systemd monitor interval set to 10000ms
[30-Oct-2020 18:28:47] NOTICE: Terminating ...
[30-Oct-2020 18:28:47] NOTICE: exiting, bye-bye!
[30-Oct-2020 18:28:47] NOTICE: fpm is running, pid 67860
[30-Oct-2020 18:28:47] NOTICE: ready to handle connections
[30-Oct-2020 18:28:47] NOTICE: systemd monitor interval set to 10000ms
I am no longer able to connect to the socket from the Docker container:
/ # REQUEST_METHOD=GET SCRIPT_FILENAME=index.php cgi-fcgi -bind -connect /run/php-fpm/www.sock
Could not connect to /run/php-fpm/www.sock
If the container is re-started, it works again.
So I imagine that the problem is related to how sockets shared in bind mounts work, but it could also be on PHP-FPM, I have no idea on how to "fix" this.
Related
sudo systemctl status redis-server.service
its ok
redis active en other port example 30000
but
redis-server --port 30000
oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5315:C 24 Aug 00:07:42.719 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=5315, just started
5315:C 24 Aug 00:07:42.719 # Configuration loaded
5315:M 24 Aug 00:07:42.720 # Creating Server TCP listening socket *:30000: bind: Address already in use
use
ps aux | grep redis
and them kill -9 process
and then
redis-server --port 30000
but iqual
Check port 30000 is not blocked by your firewall. If your redis is start on cloud, check port 30000 is added in your security group.
I'm trying install Varnish-4.1 to magento-1.9, the varnish is working fine alone but when I try to click on btn in Admin->system->Cache management, it shows the error in the title:
Failed to apply the VCL to 127.0.0.1:6082: Failed to read response code from Varnish
OS: Ubuntu 18.04
Apache: 2.4.29 (Ubuntu) port: 8080
PHP 7.1.28-1+ubuntu18.04.1
Magento ver. 1.9.4.1
varnish-4.1.11 port 80 from: https://packagecloud.io/varnishcache/varnish41/install#manual-deb
content of /etc/systemd/system/varnish.service
[Unit]
Description=Varnish HTTP accelerator
Documentation=https://www.varnish-cache.org/docs/4.1/ man:varnishd
[Service]
Type=simple
LimitNOFILE=131072
LimitMEMLOCK=82000
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T 127.0.0.1:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m -p vcc_allow_inline_c=on -p feature=+esi_ignore_other_elements -p feature=+esi_disable_xml_check
ExecReload=/usr/share/varnish/reload-vcl
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
[Install]
WantedBy=multi-user.target
sudo systemctl status varnish
● varnish.service - Varnish HTTP accelerator
Loaded: loaded (/etc/systemd/system/varnish.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/varnish.service.d
└─override.conf
Active: active (running) since Tue 2019-04-16 16:13:42 CEST; 24min ago
Docs: https://www.varnish-cache.org/docs/4.1/
man:varnishd
Main PID: 31280 (varnishd)
Tasks: 218 (limit: 4915)
CGroup: /system.slice/varnish.service
├─31280 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T 127.0.0.1:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m -p vcc_allow_inline_c=on -p feature=+esi_ignore_other_elements -p feature=+esi_disable_xml_check
└─31385 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T 127.0.0.1:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m -p vcc_allow_inline_c=on -p feature=+esi_ignore_other_elements -p feature=+esi_disable_xml_check
Apr 16 16:26:07 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37242 127.0.0.1 6082 Rd "ban" "obj.http.X-Varnish-Session" "==" "i0fmpqecahms4mi8olvi3uamk5" "&&" "obj.http.X-Turpentine-Flush-Events" "~" "core_session_abstract_add_message"
Apr 16 16:26:07 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37242 127.0.0.1 6082 Wr 200
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37246 127.0.0.1 6082 Rd "auth" "long key"
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37246 127.0.0.1 6082 Wr 200 -----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,4.18.0-17-generic,x86_64,-junix,-smalloc,-smalloc,-hcritbit
varnish-4.1.11 revision 61367ed17d08a9ef80a2d42dc84caef79cdeee7a
Type 'help' for command list.
Type 'quit' to close CLI session.
Apr 16 16:26:16 ubunut varnishd[31280]: CLI telnet 127.0.0.1 37246 127.0.0.1 6082 Rd "param.show" "feature"
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37246 127.0.0.1 6082 Wr 200 feature
Value is: +esi_disable_xml_check,+esi_ignore_other_elements
Default is: none
Enable/Disable various minor features.
none Disable all features.
Use +/- prefix to enable/disable individual feature:
short_panic Short panic message.
wait_silo Wait for persistent silo.
no_coredump No coredumps.
esi_ignore_https Treat HTTPS as HTTP in
ESI:includes
esi_disable_xml_check Don't check of body looks like
XML
esi_ignore_other_elements Ignore non-esi XML-elements
esi_remove_bom Remove UTF-8 BOM
https_scheme Also split https URIs
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37248 127.0.0.1 6082 Rd "auth" "long key"
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37248 127.0.0.1 6082 Wr 200 -----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,4.18.0-17-generic,x86_64,-junix,-smalloc,-smalloc,-hcritbit
varnish-4.1.11 revision 61367ed17d08a9ef80a2d42dc84caef79cdeee7a
Type 'help' for command list.
Type 'quit' to close CLI session.
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37248 127.0.0.1 6082 Rd "ban" "obj.http.X-Varnish-Session" "==" "i0fmpqecahms4mi8olvi3uamk5" "&&" "obj.http.X-Turpentine-Flush-Events" "~" "core_session_abstract_add_message"
Apr 16 16:26:16 ubuntu varnishd[31280]: CLI telnet 127.0.0.1 37248 127.0.0.1 6082 Wr 200
My end result that I want is to simply have it say applied successfully or something like that.
Note: I know that the secret key is put correctly with the \n. and also here is the link from where I tried install varnish:
https://www.howtoforge.com/tutorial/how-to-setup-magento-2-with-varnish-and-apache-on-ubuntu-1604/
I skipped all about lamp and magento as it was already installed and running, I only ran the commands of the varnish part.
Thanks in advance
If you want to check if Varnish is running correctly in front of Magento you can run curl -I localhost you should get a header which mention Varnish and serves the content from your backend.
I have a simple project with directory structure
I am setting up nginx config for my drupal site, and for the fastcgi_pass I have been using 127.0.0.1:9000 but I want to use a unix socket as suggested in this conf:
# PHP 7 socket location.
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
but I can't find php/php7.0-fpm.sock;
I have the following path in my centos distro
/var/run/php-fpm/php-fpm.pid
Check the php-fpm config where the socket will be created with:
$ cat /etc/php/7.0/fpm/pool.d/www.conf
Look for listen, for example:
listen = /run/php/php7.0-fpm.sock
php-fpm creates the socket file after you started the process.
sudo service php7.0-fpm stop
sudo service php7.0-fpm start
Check the directory if socket file was created:
$ cd /run/php && ls -la
First check if php-fpm is running on your system, for doing this you could use pgrep for example:
# pgrep -fa php-fpm
5666 php-fpm: master process (/etc/php-fpm.conf)
5667 php-fpm: pool www
5668 php-fpm: pool www
5669 php-fpm: pool www
5670 php-fpm: pool www
5671 php-fpm: pool www
In this case, it shows is up and running and using the configuration file /etc/php-fpm.conf. Before checking the configuration file and trying to check for the listen = directive you could quickly look into /proc/net/unix for example:
# grep php /proc/net/unix
Which may return something like:
ffff8800bfb2f400: 00000002 00000000 00010000 0001 01 28561 /tmp/php-fpm.sock
In this case, it shows that the path for the php-fpm socket is located in /tmp/php-fpm.sock the one could be verified by checking the conf in /etc/php-fpm.d/www.conf in this case being: listen= /tmp/php-fpm.sock
In case you don't get any result and php-fpm is up and running, by checking the configuration you may find that is using the defaults by listing on a TCP socket:
listen = 127.0.0.1:9000
Something you could change to listen on a Unix socket like your suggested conf:
listen = /var/run/php/php7.0-fpm.sock
In some Linux distros normally this is used:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
After modifying your configuration don't forget to restart the services systemctl restart php-fpm. To check that the socket has been created you could do:
$ file /var/run/php/php7.0-fpm.sock
If socket exists if should print out something like this:
/var/run/php/php7.0-fpm.sock: socket
you can see it by running
$ ss --unix |grep 'php'
It is likely that an older libpcre3 is installed and satisfies the dependency in the php7.0 package, but only the newer library package provides pcre_jit_stack_free.
If this is the case, do an apt-get install libpcre3, and you’re good to go.
Ref.: https://github.com/oerdnj/deb.sury.org/issues/372
I hope this helps you.
Use this:
cat /etc/php/7.0/fpm/pool.d/www.conf | grep 'listen ='
Output example: listen = /run/php/php7.2-fpm.sock
Or for universal php vesions:
cat /etc/php/$(php -r "echo PHP_VERSION;" | grep --only-matching --perl-regexp "7.\d+")/fpm/pool.d/www.conf | grep 'listen ='
I'm using docker and my container is build over php:5.6-fpm image from php official repo.
Is it somehow possible to restart/reload php-fpm from inside a container?
php-fpm is a process manager which supports the USER2 signal, which is used to reload the config file.
From inside the container:
kill -USR2 1
Outside:
docker exec -it <mycontainer> kill -USR2 1
Complete example:
docker run -d --name test123 php:7.1-fpm-alpine
docker exec -it test123 ps aux
docker exec -it test123 kill -USR2 1
docker exec -it test123 ps aux
You don't have to go inside the container
on your host
ps -ef|grep fpm // find master pid
kill -USR2 <master_pid>
This works for me:
If the command fpm restart fails run this inside the Docker container -> www#:
root#...:/var/www# **ps -ef|grep fpm**
www-data 160 1 0 10:02 ? 00:00:00 php-fpm: pool www
www-data 161 1 0 10:02 ? 00:00:00 php-fpm: pool www
root 1111 170 0 10:04 pts/0 00:00:00 grep --color=auto fpm
root#...:/var/www# **kill -USR2 170**
root#...:/home/user/Docker# **docker-compose stop**
Stopping docker_nginx_1 ... done
Stopping docker_oracle_1 ... done
root#...:/home/user/Docker# **docker-compose up -d**
Starting docker_oracle_1 ... done
Starting docker_nginx_1 ... done
root#...:/home/user/Docker# **docker-compose exec oracle bash**
root#...:/var/www# **/etc/init.d/php7.2-fpm restart**
* Restarting PHP 7.2 FastCGI Process Manager php-fpm7.2 **[ OK ]**
docker container kill --signal USR2 php_container_name
Details: https://docs.docker.com/engine/reference/commandline/container_kill/
You can also just restart the container..
sudo docker restart <container>
When I want to restart the httpd searvice on centOS 6.7 I have the following error:
/etc/init.d/httpd restart
Stopping httpd: [FAILED]
Starting httpd: (13)Permission denied: httpd: could not open error log file /etc/httpd/logs/error_log.
Unable to open logs
[FAILED]
This is error_log:
ls -Z /etc/httpd/logs/error_log
-rw-r--r--. root root unconfined_u:object_r:var_t:s0 /etc/httpd/logs/error_log
I disabled selinux also.
What is the problem?
httpd probably runs as user apache or user httpd. Your log is owned and only writable by root. Change ownership of your log file to make this work.
This should do the trick:
~# chown apache:apache /etc/httpd/logs/error_log
Probably you should change the group of that forder to apache, it's not recommended to have root as owner of server stuff. Anyway apache should change that on his own after http starts...
From httpd Wiki:
Before we start, we need to be aware that the Apache HTTP server
(httpd) runs as a particular user and group.
On Linux as well as most other Unix-like systems, httpd is started as
the "root" user; UID=root, GID=root. This is necessary because only
this user can bind to port 80 and 443 (anything below 1024 in fact).
After http starts and binds to its ports (defined by the Listen
statments in httpd.conf), it changes user to that specified in
httpd.conf. Typically:
User: apache
Group: apache
Note that Debian based systems, including
Ubuntu, use "www-data" instead.
As a possible solution you should add yourself into the group apache
usermod -a -G apache (username)
Then:
chgrp apache (folderPath)
chmod g+rwxs (folderPath)
Anyway that's weird... tell me if this solved your issue, if it didn't I will edit it as long as you provide me further information :)
In my case i have done below actions post that able to start the httpd service without any error.
Error:
# sudo tail -f /etc/httpd/logs/error_log
Sep 27 09:09:19 MASTERREPOWEB systemd[1]: Starting The Apache HTTP Server...
Sep 27 09:09:20 MASTERREPOWEB httpd[33693]: (13)Permission denied: AH00091: httpd: could not open error log file /etc/httpd/logs/error_log.
Sep 27 09:09:20 MASTERREPOWEB httpd[33693]: AH00015: Unable to open logs
Sep 27 09:09:20 MASTERREPOWEB systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
Solution:
ls -lZ /etc/httpd/logs/error_log
sudo chcon -Rv system_u:object_r:httpd_log_t:s0 /etc/httpd/logs/
sudo systemctl restart httpd
sudo systemctl status httpd
In CentOS 7
Try disabling SElinux and then reboot then
systemctl restart httpd
Note: never leave SElinux disabled. If the problem is solved then enable(enforce) it and then enable httpd in SElinux
https://www.serverlab.ca/tutorials/linux/web-servers-linux/configuring-selinux-policies-for-apache-web-servers/
If you are on RedHat/Fedora/CentOS/RockyLinux then try to execute the following command (14:00 is your time since the error happened):
journalctl -t setroubleshoot --since=14:00
You could see the following errors:
Jun 25 14:21:33 fedora setroubleshoot[1609]: SELinux is preventing httpd from open access on the file /var/log/gitea/error_log. For complete SELinux messages run: sealert -l 5e2bf467-e935-4fa7-a7fd-d0f7f257828e
Jun 25 14:21:33 fedora setroubleshoot[1609]: SELinux is preventing httpd from open access on the file /var/log/gitea/error_log.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that httpd should be allowed open access on the error_log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'httpd' --raw | audit2allow -M my-httpd
# semodule -X 300 -i my-httpd.pp
It means the lack of permissions is not related to chmod, but rather to SELinux.
In order to fix the issue you need to execute the following command (please adjust the log directory accordinly):
semanage fcontext -a -t httpd_sys_rw_content_t '/var/log/gitea(/.*)?'
restorecon -Rv '/var/log/gitea/'
systemctl restart httpd
The error should disappear. And please never switch off the SELinux permanently (as someone might suggest) because your server could be compromised.
Just run it as super user:
service httpd start
Starting httpd: (13)Permission denied: httpd: could not open error log file /etc/httpd/logs/error_log.
Unable to open logs [FAILED]
sudo service httpd start
Starting httpd: [ OK ]