Custom Query (15961 matches)
Results (1 - 3 of 15961)
Version increment to 1.4.10
Edited Test Description
When using the current php-fpm.service file from the blfs-systemd-unit files this service fails to start.
Research shows that as of February this year that Debian has a bug report open with the same issue at:
Although there also appears to be another bug with their version, the timeout for the service start is valid.
If you scroll to almost the bottom you will see a comment that they think that the issue is with the Type=notify being set in the unit file. They have almost an identical unit file to the one we are currently providing.
Seeing this hint at what the problem may be led me to make changes to my uint file as follows:
[Service] Type=forking PIDFile=/run/php-fpm.pid PrivateTmp=true ExecStart=/usr/sbin/php-fpm --daemonize --allow-to-run-as-root --fpm-config /etc/php-fpm.conf --pid /run/php-fpm.pid ExecReload=/bin/kill -USR2 $MAINPID
By using this in the unit file the service starts and remains running.
I tested various changes to that by leaving it as --nodaemonize with Type set to forking and it failed. Also it failed with --nodaemonize with type set to forking.
The --allow-to-run-as-root is needed for the main php-fpm master process. This is turned off by default in the --fpm-config file. With the master php-fpm process running as root, the child processes are run as user/group apache.
It would be nice if someone else is also able to confirm this. It has taken me a good while to track down this.
Research has also shown that other distributions back as early as 2011 had the Type=forking set in their unit files for this, though things do change over the years with different versions of systemd and the like.