somethings change with php-fpm unix sockets on ubuntu 24.04

I haven't tested those because I have not setup any website yet but my nginx apps vhost work just fine so far.

Indeed. That's why it is weird.

The error is only in monit for Ubuntu 24.04, as in 22.04 it uses the same version but works, so it must be something to do with Ubuntu 24.04 rather than monit?

 

By default the permission in www.conf php-fpm pool is only for user and group to read and write with no execution, so after changing this to allow others as well, i.e. from 0660 to 0666, it works while keeping www-data as users and group owner, so no need to change them to root.

To try:

Code:

sed -i 's/;listen.mode = 0660/listen.mode = 0666/g' /etc/php/*/fpm/pool.d/www.conf

To restore:

Code:

sed -i 's/listen.mode = 0666/;listen.mode = 0660/g' /etc/php/*/fpm/pool.d/www.conf

 

So the best would be to leave this monit error of unix socket connection as it is for now?

 

Just still curious on this. What if we temporarily change the listen.acl_users and listen.acl_groups to define two users and groups root,www-data? What is the consequence of this?

 

i tried changing the listen-mode to 0666 on my test instance, just to see what it did, monit is still failing the unix socket test with the same message

Code:

[2024-08-06T11:24:40+0000] error    : Unix socket /var/run/php/php8-2-fpm.sock connection error -- No such file or directory
[2024-08-06T11:24:40+0000] error    : 'php8.2-fpm' failed protocol test [DEFAULT] at /var/run/php/php8-2-fpm.sock -- Cannot create unix socket for /var/run/php/php8-2-fpm.sock
[2024-08-06T11:24:40+0000] info     : 'php8.2-fpm' trying to restart
[2024-08-06T11:24:40+0000] info     : 'php8.2-fpm' stop: '/usr/bin/systemctl stop php8.2-fpm'
[2024-08-06T11:24:40+0000] info     : 'php8.2-fpm' start: '/usr/bin/systemctl start php8.2-fpm'

i can't see anything about it already on the monit issues tracker, so i've submitted one for it there.
https://bitbucket.org/tildeslash/monit/issues/1109/unable-to-monitor-php-fpm-unixsockets-on

 

for those running the latest debian, i assume you're not seeing any of these issues on there.

it's been suggested to check this:

so if someone who's already got the latest debian running, can you see if this file exists on there, and if so, post the contents, so i can compare it to the file on ubuntu.

 

ok. in lieu of reading the whole docs, i renamed /lib/systemd/system/monit.service and restarted the service..

got this message:
Warning: The unit file, source configuration file or drop-ins of monit.service changed on disk. Run 'systemctl daemon-reload' to reload units.

did that, and now the unixsocket tests for php#.#-fpm are working properly.
so it’s definitely something set in that file causing the problem.. now just need to find out what..
not sure on the security implications of not having that file at all, so would be interesting to find out how it differs between ubuntu and debian.

 

Due to security reason warned by @till, I didn't use any of the temporary fixes for Ubuntu 24.0 monit except the one in my last reply (#26), though I did test them by stopping all php-fpm services and restarting them back, otherwise it won't work, simply because php-fpm can only use its new config(s) after it has restarted.

For #26, I ran:

Code:

sed -i 's/;listen.acl_users =/listen.acl_users = root,www-data/g' /etc/php/*/fpm/pool.d/www.conf
sed -i 's/;listen.acl_groups =/listen.acl_groups = root,www-data/g' /etc/php/*/fpm/pool.d/www.conf

This should allow only www-data and root to work, but no others, so I think it is safe.

 

ok found it.. and debian 12 doesn’t display the same problem, /lib/systemd/system/monit.service file doesn’t exist on debian 12, or previous versions of ubuntu.

although the monit.service file does exist in /usr/share/docs on debian 12, so it might be something they’ve just not fully implemented yet and will affect debian later..
the debian file in /usr/share/docs also matches the ubuntu version but without the hardening options section.

‌and the problem line is
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW CAP_SYS_PTRACE

replace CAP_DAC_READ with CAP_DAC_OVERRIDE
run

Code:

systemctl daemon-reload
systemctl restart monit

and the ' if failed unixsocket /var/run/php/php#.#-fpm.sock then restart' test starts working properly again.

list of the capabilities and how to enable/restrict them are here https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Capabilities and here: https://man7.org/linux/man-pages/man7/capabilities.7.html.

i can confirm @ahrasis solution of adding root,www-data to the listen.acl_users and listen.acl_groups in each php's www.conf pool file also works without changing the original monit.service file.

no idea which method is more secure, or more update safe, so take your pick, although i can see this ending up affecting sockets for other services where modifying the acl lists won't be as easy as it is for php.
i also suspect the problem will jump from ubuntu to debian soon as well.

 

The best is to fix monit, if the problem is due to it but I do not suspect it because as you reported, the same version is used in 22.04 with no problem.

My guess is more on php compilation for Ubuntu 24.04 which is different from Ubuntu 22.04. Not sure about Debian though.

I doubt other unix socket faced the same problem but who knows until there is report on it.

 

it's not anything different with php, it's the existence of /lib/systemd/system/monit.service with hardening options restricting what monit is allowed to do.

ubuntu 22.04 (and earlier) doesn't have the /lib/systemd/system/monit.service file, which contains the hardening options.
nor does any of the debian versions. that's why they're not affected.
i expect if that file was applied to the monit service on any of those releases they would have the same problem, and the fact that file is included in /usr/share/docs on debian12, albeit currently without the hardening options section, leads me to believe that it's something that is going to happen to debian, but they just haven't got it to the release stage yet.

the capabilities set in that file are the only ones the monit service is allowed, anything not included is not allowed,
and the differences between CAP_DAC_READ and CAP_DAC_OVERRIDE are:

so it seems, since the php-fpm service is run by root, but the socket is owned by www-data monit can't check both the process and the socket, since it's not allowed to write to the socket as root, but it has no problem checking the process and socket for fail2ban or mariadb, as both the process and socket use the same owner.

if the php#.#=fpm services were started as www-data instead of root, the process owner and socket owners would match, and monit would never have this problem, even with if the default hardening optons are applied to the monit service

 

If you check both fail2ban and mariadb config for monit you will know that fail2ban socket is owned by root, so that definitely faces no problem, however, mariadb (uses mysqld) socket is owned by mysql but it faces no problem. That is why my theory was it could be php-fpm compilation for Ubuntu 24.04 because mariadb unix socket works just fine though it is not owned by root. If the monit systemd settings are simply hardened, and should fail unix socket not owned by root, then mariadb unix socket could also fail but it did not.

 

Thanks so much for your complete answer...

I did "systemctl edit monit", and then add following lines:

Code:

[Service]
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW CAP_SYS_PTRACE CAP_DAC_READ CAP_DAC_OVERRIDE

Then performed a "systemctl daemon-reload" and restarted monit.
Now monit can monitor php fpm socket like a charm!

Thank you very much!

 

Not that I am against this changing of monit configs but I also think that the hardening options are there for reasons, so I won't be lowering that options unless I fully understand its consequences as a whole and not just only for php-fpm unix socket. For now, I only understand such a monit's change works but not of its consequences as whole. Anyway, if that is safe, may be ISPConfig developer can include that in its installer package or its auto installer.