php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #78889 php-fpm service fails to start
Submitted: 2019-11-29 21:30 UTC Modified: 2019-12-01 17:29 UTC
Votes:3
Avg. Score:3.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: glitsj16 at riseup dot net Assigned: bukka (profile)
Status: Closed Package: FPM related
PHP Version: 7.4.0 OS: Arch Linux
Private report: No CVE-ID: None
View Developer Edit
 [2019-11-29 21:30 UTC] glitsj16 at riseup dot net 
Description:
------------
php-fpm.service fails to start after upgrading to php 7.4.0. Using the default configuration files.

systemctl status php-fpm.service:

systemd[1]: Starting The PHP FastCGI Process Manager...
php-fpm[10704]: [ERROR] [pool www] failed to chown() the socket '/run/php-fpm/php-fpm.sock': Operation not permitted (1)
php-fpm[10704]: [ERROR] [pool www] failed to chown() the socket '/run/php-fpm/php-fpm.sock': Operation not permitted (1)
php-fpm[10704]: [ERROR] FPM initialization failed
php-fpm[10704]: [ERROR] FPM initialization failed
systemd[1]: php-fpm.service: Main process exited, code=exited, status=78/CONFIG
systemd[1]: php-fpm.service: Failed with result 'exit-code'.
systemd[1]: Failed to start The PHP FastCGI Process Manager.

This has been reported in the Arch bug tracker: https://bugs.archlinux.org/task/64683
Looks like the CapabilityBoundingSet needs to include CAP_CHOWN

Patches

php-fpm.service.in.patch (last revision 2019-11-29 21:30 UTC by glitsj16 at riseup dot net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-11-30 01:21 UTC] glitsj16 at riseup dot net 
During ongoing discussion in https://bugs.archlinux.org/task/64683 it was suggested to leave the CapabilityBoundingSet as-is, but edit /etc/php/php-fpm.d/www.conf instead. This looks the cleaner way of fixing this.

https://bugs.archlinux.org/task/64683#comment184101

In /etc/php/php-fpm.d/www.conf replace
;listen.acl_users =
;listen.acl_groups =
with
listen.acl_users = http
listen.acl_groups = http

https://bugs.archlinux.org/task/64683#comment184102

@loqs Enabling ACL in /etc/php/php-fpm.d/www.conf as you suggested works for me. I also commented
;listen.owner = http
;listen.group = http
to avoid
[WARNING] [pool www] ACL set, listen.owner = 'http' is ignored
[WARNING] [pool www] ACL set, listen.group = 'http' is ignored
in systemctl status php-fpm.service

Doing so deprecates the attached patch. It is up to the devs whether or not the needed changes to www.conf can be left for maintainers to implement or if anything can be done by upstream.
 [2019-11-30 13:38 UTC] cmb@php.net 
Related To: Bug #78892
 [2019-11-30 13:39 UTC] cmb@php.net
-Assigned To: +Assigned To: bukka
 [2019-11-30 13:39 UTC] cmb@php.net 
Jakub, could you please check this?
 [2019-11-30 16:44 UTC] build+php at de-korte dot org 
I don't want to be picking nits, but in the default configuration, php-fpm will listen to an AF_INET socket (127.0.0.1:9000), not an AF_UNIX socket (/run/php-fpm/php-fpm.sock) like mentioned in this report. The reported issue will only occur in the latter case, not in the first (which is the default).
 [2019-11-30 17:16 UTC] glitsj16 at riseup dot net 
The bug is inded triggered when using an AF_UNIX socket. That should have been caught by the downstream Arch maintainer(s) who decided to change the defaults and broke the php-fpm service. This has been rectified via the 7.4.0-2 release so I think this can be closed. Thanks for looking into this.
 [2019-12-01 09:18 UTC] ilya at ilya dot pp dot ua 
FPM is part of PHP.
systemd-unit file is shipped in the PHP tarball.
They decided to add a CapabilityBoundingSet to it, but they didn’t add it completely, they forgot to add CAP_CHOWN.
Why do you think this is not a PHP bug?

That is, in your opinion, the administrator of the web server, in addition to the configuration files, must also configure the systemd-unit file itself, if it changes something in the configuration file?
 [2019-12-01 12:14 UTC] fgfgfgfg at somewhere dot com 
> that is, in your opinion, the administrator of the 
> web server, in addition to the configuration files, 
> must also configure the systemd-unit file itself, 
> if it changes something in the configuration file?

surely

that's what /etc/systemd/systemd/servicename.service.d/ dropins are for or in case of the distribution /usr/lib/systemd/system/servicename.service.d/

if you change or add something you are supposed to know what you are doing
 [2019-12-01 13:07 UTC] nikic@php.net 
For reference, this was added in https://github.com/php/php-src/commit/40c4d7f1820df1872a71ab07fd26da45a203e37f. Adding CAP_CHOWN sounds reasonable.

What also jumps out to me is that this enables MemoryDenyWriteExecute, which seems like a very bad idea, as it should break PCRE JIT. Unless I misunderstand what this file applies to.
 [2019-12-01 17:13 UTC] bukka@php.net 
Automatic comment on behalf of bukka
Revision: http://git.php.net/?p=php-src.git;a=commit;h=67cd4271e922ee3082b416a7563598274d13a1e5
Log: Fix bug #78889 (php-fpm service fails to start)
 [2019-12-01 17:13 UTC] bukka@php.net
-Status: Assigned +Status: Closed
 [2019-12-01 17:17 UTC] bukka@php.net 
Automatic comment on behalf of bukka
Revision: http://git.php.net/?p=php-src.git;a=commit;h=67cd4271e922ee3082b416a7563598274d13a1e5
Log: Fix bug #78889 (php-fpm service fails to start)
 [2019-12-01 17:29 UTC] bukka@php.net 
So I identified potentially another missing capability for chroot and not really sure if there are more. So I removed CapabilityBoundingSet completely for PHP 7.4. I created a PR that could re-introduce it in master with all capabilities needed: https://github.com/php/php-src/pull/4960 . If you can think of any, please add a comment.

In addition I removed MemoryDenyWriteExecute as I agree with Nikita that this could break PCRE JIT.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 12:00:01 2025 UTC