PHP-FPM via socket: questions

OS type and version Redhat Enterprise Linux 8
Webmin version 1.984
Virtualmin version 6.17
Related packages php-fpm 8.0.16 (via remi) Apache 2.4.37


I switched a test website running LAMP WordPress to socket vs TCP port, and I have some questions about ownership of the .sock file.

When I run the command to switch from port to socket, the .sock file gets owned by root:root. Loading the website in a browser gives a 503 Gateway error. Changing ownership of the .sock via chown to apache:apache or twebblog:twebblog (where twebblog is the virtual server owner/user) makes the site function normally, 200.

Restarting php-fpm via the Virtualmin dashboard or systemctl changes the .sock file owner back to root:root, and website = 503 error.

Is this expected behavior, or do I have something misconfigured? I would love to have the .sock file owned by twebblog:twebblog “permanently”, so I don’t have to constantly watch and change the ownership of the .sock whenever services are restarted.

No, the file is expected to be owned by user. Did you have it enabled in System Settings ⇾ Server Templates: Edit Server Template / PHP Options using FPM server connection option?

When I run the command to switch from port to socket,

What command did you run exactly?

Thanks, Ilia.

Command I ran to switch the server from port to socket:
virtualmin modify-web --domain twebblog.domain.tld --php-fpm-socket

I did not have the PHP Options FPM server connection set to Unix socket. I have now changed that setting in the default template. Additionally, I have saved the settings for the virtual server via Edit Virtual Server and Services: PHP-FPM Configuration.

If I restart PHP-FPM 8.0.16 Server via Dashboard, the socket process is again owned by root:

$ ls -al /var/php-fpm/1637945577899053.sock
srw-rw---- 1 root root 0 Feb 23 08:14 /var/php-fpm/1637945577899053.sock


sudo chown twebblog:twebblog /var/php-fpm/1637945577899053.sock
[sudo] password for xxxxxxx:
[xxxxxx@tweb12 ~]$ ls -al /var/php-fpm/1637945577899053.sock
srw-rw---- 1 twebblog twebblog 0 Feb 23 08:14 /var/php-fpm/1637945577899053.sock

Then, restart PHP-FPM 8.0.16 via Dashboard. Once again:

$ ls -al /var/php-fpm/1637945577899053.sock
srw-rw---- 1 root root 0 Feb 23 08:26 /var/php-fpm/1637945577899053.sock

Possibly the Services: PHP-FPM Configuration per virtual server should have the following enabled or added by default?

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server.
; Default Values: user and group are set as the running user
;	          mode is set to 0660
listen.owner = twebblog = twebblog
listen.mode = 0660

I tried creating a new virtual server with the new default template setting. There is no listen.owner, nor, nor listen.mode in the conf file:

user = random
group = random
listen = /var/php-fpm/16456408833947164.sock
pm = dynamic
pm.max_children = 20
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 5
php_admin_value[upload_tmp_dir] = /tvirtualmin/random/tmp
php_admin_value[session.save_path] = /tvirtualmin/random/tmp

It looks like any new virtual server’s .sock file is also owned by root:

$ ls -al /var/php-fpm/
total 4
drwxr-xr-x   2 root     root       65 Feb 23 13:35 .
drwxr-xr-x. 26 root     root     4096 Feb 22 11:04 ..
srw-rw----   1 twebblog twebblog    0 Feb 23 12:38 1637945577899053.sock
srw-rw----   1 root     root        0 Feb 23 13:35 16456412973950861.sock

One additional observation: virtualmin transfer-domain does not seem to update the Services: PHP-FPM configuration from the primary server to the replica server.

@Ilia Do you have any insight or information on why the php-fpm .sock would not be owned by the virtual server account? PHP-FPM config file does not have listen.owner or I have tried creating new virtual server with my RHEL 8 system, default PHP 8.0 via Remi, and the .sock is owned by root upon creation of the server, and on php-fpm restart.

I can test on different systems (Pro Centos 6, GPL RHEL 8 or Ubuntu 20).

@Jamie, do you remember fixing this issue?

1 Like

Yes, a fix for this was implemented and will be included in the Virtualmin 7.0 release.


This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.