php: fpm sapi: install startup script

PATCH New Floris Bos 2 participants 6 messages Apr 30, 2015 – May 1, 2015

lore

Share & tools

lore

Floris Bos

author

2015-04-30 19:36 UTC #0 lore raw

PATCH 1/1 php: fpm sapi: install startup script

When PHP's FastCGI Process Manager SAPI is selected:

- install a startup script.
- install a simple configuration, using the ondemand process manager that only starts children when the website is actually being used.

Signed-off-by Floris Bos <[email protected]>

---
 package/php/php-fpm.conf | 14 ++++++++++++++
 package/php/php.mk       | 15 +++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 package/php/php-fpm.conf

package/php/php-fpm.conf new file +14 -0

new file mode 100644
index 0000000..2ffe595
@@ -0,0 +1,14 @@
+[www]
+# Only start children when there are requests to be processed
+pm = ondemand
+# Terminate them again after there haven't been any for 2 minutes
+pm.process_idle_timeout = 120s
+# Maximum number of children processing PHP requests concurrently
+pm.max_children = 32
+
+listen = /var/run/php-fpm.sock
+listen.owner = www-data
+listen.group = www-data
+user = www-data
+group = www-data
+

package/php/php.mk +15 -0

index e4331f2..6c42aba 100644
@@ -251,6 +251,21 @@ PHP_CONF_OPTS += \
 PHP_DEPENDENCIES += jpeg libpng freetype
 endif
 
+ifeq ($(BR2_PACKAGE_PHP_FPM),y)
+define PHP_INSTALL_INIT_SYSV
+	$(INSTALL) -D -m 0755 $(@D)/sapi/fpm/init.d.php-fpm \
+		$(TARGET_DIR)/etc/init.d/S49php-fpm
+endef
+
+define PHP_INSTALL_FPM_CONF
+	$(INSTALL) -D -m 0644 package/php/php-fpm.conf \
+		$(TARGET_DIR)/etc/php-fpm.conf
+	rm -f $(TARGET_DIR)/etc/php-fpm.conf.default
+endef
+
+PHP_POST_INSTALL_TARGET_HOOKS += PHP_INSTALL_FPM_CONF
+endif
+
 define PHP_EXTENSIONS_FIXUP
 	$(SED) "/prefix/ s:/usr:$(STAGING_DIR)/usr:" \
 		$(STAGING_DIR)/usr/bin/phpize

Signature · 1 line

2.1.4

Arnout Vandecappelle

2015-04-30 20:27 UTC #1 lore raw

PATCH 1/1 php: fpm sapi: install startup script

Quoted 5 lines · Floris Bos

When PHP's FastCGI Process Manager SAPI is selected:
- install a startup script.
- install a simple configuration, using the ondemand process manager that only starts children when the website is actually being used.

Correct me if I'm wrong, but what is still missing is the configuration of the
webserver to actually use this, right? You still have to update your webserver configuration to point to /var/run/php-fpm.sock to handle php scripts, right?

If so, perhaps that could be explained in the help text in php/Config.in.

It may also be good to explain in the commit log why you don't use the provided
default config file

Quoted 14 lines

Signed-off-by Floris Bos <[email protected]>

---
 package/php/php-fpm.conf | 14 ++++++++++++++
 package/php/php.mk       | 15 +++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 package/php/php-fpm.conf

package/php/php-fpm.conf new file +0 -0

new file mode 100644
index 0000000..2ffe595

package/php/php-fpm.conf line 7

Quoted 7 lines

package/php/php-fpm.conf new file +7 -0

@@ -0,0 +1,14 @@
+[www]
+# Only start children when there are requests to be processed
+pm = ondemand
+# Terminate them again after there haven't been any for 2 minutes
+pm.process_idle_timeout = 120s
+# Maximum number of children processing PHP requests concurrently
+pm.max_children = 32

Isn't that a bit high? Typically embedded web servers will not have the power
to handle that many parallel requests efficiently.

Quoted 12 lines

package/php/php-fpm.conf new file +7 -0

+
+listen = /var/run/php-fpm.sock
+listen.owner = www-data
+listen.group = www-data
+user = www-data
+group = www-data
+

package/php/php.mk +0 -0

index e4331f2..6c42aba 100644

package/php/php.mk PHP_CONF_OPTS += \ · line 258

Quoted 8 lines

package/php/php.mk +5 -0

@@ -251,6 +251,21 @@ PHP_CONF_OPTS += \
 PHP_DEPENDENCIES += jpeg libpng freetype
 endif
 
+ifeq ($(BR2_PACKAGE_PHP_FPM),y)
+define PHP_INSTALL_INIT_SYSV
+	$(INSTALL) -D -m 0755 $(@D)/sapi/fpm/init.d.php-fpm \
+		$(TARGET_DIR)/etc/init.d/S49php-fpm
+endef

There's also a php-fpm.service that you can install for systemd.

Regards,
Arnout

Quoted 14 lines

package/php/php.mk +10 -0

+
+define PHP_INSTALL_FPM_CONF
+	$(INSTALL) -D -m 0644 package/php/php-fpm.conf \
+		$(TARGET_DIR)/etc/php-fpm.conf
+	rm -f $(TARGET_DIR)/etc/php-fpm.conf.default
+endef
+
+PHP_POST_INSTALL_TARGET_HOOKS += PHP_INSTALL_FPM_CONF
+endif
+
 define PHP_EXTENSIONS_FIXUP
 	$(SED) "/prefix/ s:/usr:$(STAGING_DIR)/usr:" \
 		$(STAGING_DIR)/usr/bin/phpize

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

Floris Bos

author

2015-04-30 22:15 UTC #2 lore raw

PATCH 1/1 php: fpm sapi: install startup script

Hi,

Quoted 9 lines · Arnout Vandecappelle

Quoted 5 lines · Floris Bos
When PHP's FastCGI Process Manager SAPI is selected:
- install a startup script.
- install a simple configuration, using the ondemand process manager that only starts children when the website is actually being used.
Correct me if I'm wrong, but what is still missing is the configuration of the
webserver to actually use this, right? You still have to update your webserver configuration to point to /var/run/php-fpm.sock to handle php scripts, right?

Correct.
Although I am thinking about submitting a subsequent patch that adds an option to enable it in the webserver configuration.

I know that may go against the "tradition" that buildroot only does the compiling, and the user has to do his own configuration.
But things like enabling PHP in a webserver configuration is one of those annoying repetitive tasks that I really like to see handled by ticking a box.

Quoted 5 lines

If so, perhaps that could be explained in the help text in php/Config.in.
It may also be good to explain in the commit log why you don't use the provided
default config file

The stock php-fpm config is good for illustrative purposes only. It is unfit for multi-user systems, as it listens to a TCP socket with no authentication, allowing any local user that knows how to connect to 127.0.0.1:9000 to elevate privileges and execute arbitrary code as the php user.
And it uses a pm that keeps a minimum number of PHP children resident at all times, making it not the best choice for embedded systems either.

Quoted 7 lines

Quoted 7 lines
Signed-off-by Floris Bos <[email protected]>
---
  package/php/php-fpm.conf | 14 ++++++++++++++
  package/php/php.mk       | 15 +++++++++++++++
  2 files changed, 29 insertions(+)
create mode 100644 package/php/php-fpm.conf

Quoted 15 lines

package/php/php-fpm.conf line 7
Quoted 13 lines
package/php/php-fpm.conf new file +7 -0
new file mode 100644
index 0000000..2ffe595
@@ -0,0 +1,14 @@
+[www]
+# Only start children when there are requests to be processed
+pm = ondemand
+# Terminate them again after there haven't been any for 2 minutes
+pm.process_idle_timeout = 120s
+# Maximum number of children processing PHP requests concurrently
+pm.max_children = 32
Isn't that a bit high? Typically embedded web servers will not have the power
to handle that many parallel requests efficiently.

Some of the web applications we use feature an AJAX web interface that uses a form of "long polling" to poll for certain events. That essentially ties up a PHP process per logged-in user, so I like the number a bit higher than usual.
Doesn't consume much resources (at least not cpu), but does block for 29 seconds if no events come in.
Also scripts that query data from external servers can block as well.

The number could be made a little lower, as not everybody does stuff like that.
But it doesn't really harm others either, as extra children are only started if all the existing ones are occupied. Not by default.

Quoted 16 lines

package/php/php-fpm.conf new file +7 -0

+
+listen = /var/run/php-fpm.sock
+listen.owner = www-data
+listen.group = www-data
+user = www-data
+group = www-data
+

package/php/php.mk +0 -0

index e4331f2..6c42aba 100644
@@ -251,6 +251,21 @@ PHP_CONF_OPTS += \
  PHP_DEPENDENCIES += jpeg libpng freetype
  endif

Quoted 6 lines

package/php/php.mk PHP_CONF_OPTS += \ · line 258
Quoted 5 lines
package/php/php.mk +5 -0
+ifeq ($(BR2_PACKAGE_PHP_FPM),y)
+define PHP_INSTALL_INIT_SYSV
+	$(INSTALL) -D -m 0755 $(@D)/sapi/fpm/init.d.php-fpm \
+		$(TARGET_DIR)/etc/init.d/S49php-fpm
+endef
There's also a php-fpm.service that you can install for systemd.

Yes, I noticed that before submitting the patch. But I never had much luck with systemd on buildroot.

The .service file generated by the PHP build did not work as-is when I tried it this morning.

==
Konsole output [Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target

[Service]
Type=simple
PIDFile=/var/run/php-fpm.pid ExecStart=${exec_prefix}/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target
==

First problem was that systemd didn't like the ${exec_prefix} And I am not sure if we have the syslog.target either.

But another thing I noticed was that my webserver and my other custom applications were not starting properly with systemd anymore. Seems for some reason /tmp is not world-writable anymore.
So if your application does not run as root, and wants to create a file in say /var/log (that links to /tmp) it fails.
Haven't yet figured out what is up with that.

Yours sincerely,

Floris Bos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150501/b4027343/attachment.html>

Arnout Vandecappelle

2015-04-30 23:20 UTC #3 lore raw

PATCH 1/1 php: fpm sapi: install startup script

Quoted 13 lines · Floris Bos

Hi,
Quoted 9 lines · Arnout Vandecappelle
Quoted 5 lines · Floris Bos
When PHP's FastCGI Process Manager SAPI is selected:
- install a startup script.
- install a simple configuration, using the ondemand process manager that only starts children when the website is actually being used.
Correct me if I'm wrong, but what is still missing is the configuration of the
webserver to actually use this, right? You still have to update your webserver configuration to point to /var/run/php-fpm.sock to handle php scripts, right?

Quoted 6 lines

Correct.
Although I am thinking about submitting a subsequent patch that adds an option to enable it in the webserver configuration.
I know that may go against the "tradition" that buildroot only does the compiling, and the user has to do his own configuration.

No, the tradition is that as much as possible it works out of the box, but in
the most simple way. As long as it is easy to customize in post-build and/or overlay.

Quoted 2 lines

But things like enabling PHP in a webserver configuration is one of those annoying repetitive tasks that I really like to see handled by ticking a box.

I fully agree.

Quoted 7 lines

Quoted 6 lines
If so, perhaps that could be explained in the help text in php/Config.in.
It may also be good to explain in the commit log why you don't use the provided
default config file

Quoted 6 lines

The stock php-fpm config is good for illustrative purposes only.
It is unfit for multi-user systems, as it listens to a TCP socket with no authentication, allowing any local user that knows how to connect to 127.0.0.1:9000 to elevate privileges and execute arbitrary code as the php user. And it uses a pm that keeps a minimum number of PHP children resident at all times, making it not the best choice for embedded systems either.

I fully agree, just thought it should be mentioned in the commit message.

Quoted 24 lines

Quoted 8 lines
Quoted 8 lines
Signed-off-by Floris Bos <[email protected]>
---
 package/php/php-fpm.conf | 14 ++++++++++++++
 package/php/php.mk       | 15 +++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 package/php/php-fpm.conf
Quoted 15 lines
package/php/php-fpm.conf line 7
Quoted 13 lines
package/php/php-fpm.conf new file +7 -0
new file mode 100644
index 0000000..2ffe595
@@ -0,0 +1,14 @@
+[www]
+# Only start children when there are requests to be processed
+pm = ondemand
+# Terminate them again after there haven't been any for 2 minutes
+pm.process_idle_timeout = 120s
+# Maximum number of children processing PHP requests concurrently
+pm.max_children = 32
Isn't that a bit high? Typically embedded web servers will not have the power
to handle that many parallel requests efficiently.

Quoted 2 lines

Some of the web applications we use feature an AJAX web interface that uses a form of "long polling" to poll for certain events.

I thought long polling was exactly the opposite: close the connection and poll
again later. But I don't know about these things :-)

Quoted 9 lines

That essentially ties up a PHP process per logged-in user, so I like the number a bit higher than usual.
Doesn't consume much resources (at least not cpu), but does block for 29 seconds if no events come in.
Also scripts that query data from external servers can block as well.
The number could be made a little lower, as not everybody does stuff like that. But it doesn't really harm others either, as extra children are only started if all the existing ones are occupied. Not by default.

However, in a memory-constrained system (which still is one of buildroot's core
targets), it will trigger OOM when there actually are so many children.

Quoted 42 lines

Quoted 18 lines
Quoted 18 lines
package/php/php-fpm.conf new file +7 -0
+
+listen = /var/run/php-fpm.sock
+listen.owner = www-data
+listen.group = www-data
+user = www-data
+group = www-data
+
package/php/php.mk +0 -0
index e4331f2..6c42aba 100644
@@ -251,6 +251,21 @@ PHP_CONF_OPTS += \
 PHP_DEPENDENCIES += jpeg libpng freetype
 endif
 
Quoted 6 lines
package/php/php.mk PHP_CONF_OPTS += \ · line 258
Quoted 5 lines
package/php/php.mk +5 -0
+ifeq ($(BR2_PACKAGE_PHP_FPM),y)
+define PHP_INSTALL_INIT_SYSV
+	$(INSTALL) -D -m 0755 $(@D)/sapi/fpm/init.d.php-fpm \
+		$(TARGET_DIR)/etc/init.d/S49php-fpm
+endef
There's also a php-fpm.service that you can install for systemd.
Yes, I noticed that before submitting the patch. But I never had much luck with systemd on buildroot.
The .service file generated by the PHP build did not work as-is when I tried it this morning.
==
Konsole output [Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target
[Service]
Type=simple
PIDFile=/var/run/php-fpm.pid
ExecStart=${exec_prefix}/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf ExecReload=/bin/kill -USR2 $MAINPID

Quoted 5 lines

[Install]
WantedBy=multi-user.target
==
First problem was that systemd didn't like the ${exec_prefix}

That should probably have been substituted away by the conf.in -> conf
conversion...

Quoted 1 line

And I am not sure if we have the syslog.target either.

I believe journald provides that.

Quoted 6 lines

But another thing I noticed was that my webserver and my other custom applications were not starting properly with systemd anymore. Seems for some reason /tmp is not world-writable anymore.
So if your application does not run as root, and wants to create a file in say /var/log (that links to /tmp) it fails.

I guess whoever uses systemd will deal with that.

Personally, I think it's worthwhile to install the service file even if it is
not working. If nobody actually uses it, there's no harm done. If someone does use it, they're no worse off than if there was not service file. And they may give us a patch that fixes the problem.

Regards,
Arnout

Quoted 7 lines

Haven't yet figured out what is up with that.
Yours sincerely,
Floris Bos

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

Floris Bos

author

2015-05-01 10:42 UTC #4 lore raw

PATCH 1/1 php: fpm sapi: install startup script

Quoted 22 lines · Arnout Vandecappelle

Quoted 22 lines
Quoted 22 lines
Quoted 13 lines
Signed-off-by Floris Bos <[email protected]>
---
  package/php/php-fpm.conf | 14 ++++++++++++++
  package/php/php.mk       | 15 +++++++++++++++
  2 files changed, 29 insertions(+)
create mode 100644 package/php/php-fpm.conf
package/php/php-fpm.conf new file +0 -0
new file mode 100644
index 0000000..2ffe595
package/php/php-fpm.conf line 7
Quoted 7 lines
package/php/php-fpm.conf new file +7 -0
@@ -0,0 +1,14 @@
+[www]
+# Only start children when there are requests to be processed
+pm = ondemand
+# Terminate them again after there haven't been any for 2 minutes
+pm.process_idle_timeout = 120s
+# Maximum number of children processing PHP requests concurrently
+pm.max_children = 32
Isn't that a bit high? Typically embedded web servers will not have the power
to handle that many parallel requests efficiently.

Quoted 4 lines

Quoted 2 lines
Some of the web applications we use feature an AJAX web interface that uses a form of "long polling" to poll for certain events.
I thought long polling was exactly the opposite: close the connection and poll
again later. But I don't know about these things :-)

Letting the client Javascript code poll at set intervals -e.g. every second- and the server returning a response immediately each time, is traditional polling.

With long polling you let the client wait LONG for the response instead. The server (PHP code) delays sending the response until there is new data to report, or a timeout happens (29 seconds in our case) after which a dummy response is sent to keep the line open, and the client sends a new long poll request immediately.
Advantage is that the client receives the new data as soon as it is available, and does not have to have to wait until the next client poll interval, resulting in a smoother user experience.
Downside is that it esentially ties up at least one PHP process per logged-in webinterface user, just for the polling.

Quoted 7 lines

Quoted 7 lines
That essentially ties up a PHP process per logged-in user, so I like the number a bit higher than usual.
Doesn't consume much resources (at least not cpu), but does block for 29 seconds if no events come in.
Also scripts that query data from external servers can block as well.

Quoted 5 lines

Quoted 3 lines
The number could be made a little lower, as not everybody does stuff like that. But it doesn't really harm others either, as extra children are only started if all the existing ones are occupied. Not by default.
However, in a memory-constrained system (which still is one of buildroot's core
targets), it will trigger OOM when there actually are so many children.

So how many would you recommend as buildroot default? 2? 4? 8? 16?

Quoted 39 lines

Quoted 39 lines
Quoted 16 lines
Quoted 16 lines
package/php/php-fpm.conf new file +7 -0
+
+listen = /var/run/php-fpm.sock
+listen.owner = www-data
+listen.group = www-data
+user = www-data
+group = www-data
+
package/php/php.mk +0 -0
index e4331f2..6c42aba 100644
@@ -251,6 +251,21 @@ PHP_CONF_OPTS += \
  PHP_DEPENDENCIES += jpeg libpng freetype
  endif
 
Quoted 6 lines
package/php/php.mk PHP_CONF_OPTS += \ · line 258
Quoted 5 lines
package/php/php.mk +5 -0
+ifeq ($(BR2_PACKAGE_PHP_FPM),y)
+define PHP_INSTALL_INIT_SYSV
+	$(INSTALL) -D -m 0755 $(@D)/sapi/fpm/init.d.php-fpm \
+		$(TARGET_DIR)/etc/init.d/S49php-fpm
+endef
There's also a php-fpm.service that you can install for systemd.
Yes, I noticed that before submitting the patch. But I never had much luck with systemd on buildroot.
The .service file generated by the PHP build did not work as-is when I tried it this morning.
==
Konsole output [Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target
[Service]
Type=simple
PIDFile=/var/run/php-fpm.pid
ExecStart=${exec_prefix}/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf ExecReload=/bin/kill -USR2 $MAINPID

Quoted 7 lines

Quoted 5 lines
[Install]
WantedBy=multi-user.target
==
First problem was that systemd didn't like the ${exec_prefix}
That should probably have been substituted away by the conf.in -> conf
conversion...

Also seems to happen when compiling PHP outside of buildroot.

==
max at lynx:/tmp/p/php-5.6.8/sapi/fpm$ cat php-fpm.service [Unit]
Description=The PHP FastCGI Process Manager After=syslog.target network.target

[Service]
Type=simple
PIDFile=${prefix}/var/run/php-fpm.pid ExecStart=${exec_prefix}/sbin/php-fpm --nodaemonize --fpm-config ${prefix}/etc/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

max at lynx:/tmp/p/php-5.6.8/sapi/fpm$ cat php-fpm.service.in [Unit]
Description=The PHP FastCGI Process Manager After=syslog.target network.target

[Service]
Type=@php_fpm_systemd@ PIDFile=@localstatedir@/run/php-fpm.pid ExecStart=@sbindir@/php-fpm --nodaemonize --fpm-config @sysconfdir@/php-fpm.conf ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

Is that a bug in PHP, or does systemd support variables in .service descriptions like this, and is the real problem perhaps that we are failing to set exec_prefix in some kind of global systemd environment file?

Yours sincerely,

Floris Bos

Arnout Vandecappelle

2015-05-01 12:48 UTC #5 lore raw

PATCH 1/1 php: fpm sapi: install startup script

Quoted 1 line · Floris Bos

On 05/01/2015 01:20 AM, Arnout Vandecappelle wrote:

[snip]

Quoted 12 lines

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
package/php/php-fpm.conf line 7
Quoted 2 lines
package/php/php-fpm.conf new file +2 -0
+# Maximum number of children processing PHP requests concurrently
+pm.max_children = 32
Isn't that a bit high? Typically embedded web servers will not have the power
to handle that many parallel requests efficiently.
Some of the web applications we use feature an AJAX web interface that uses a form of "long polling" to poll for certain events.
I thought long polling was exactly the opposite: close the connection and poll
again later. But I don't know about these things :-)
Letting the client Javascript code poll at set intervals -e.g. every second- and the server returning a response immediately each time, is traditional polling.

Quoted 10 lines

With long polling you let the client wait LONG for the response instead. The server (PHP code) delays sending the response until there is new data to report, or a timeout happens (29 seconds in our case) after which a dummy response is sent to keep the line open, and the client sends a new long poll request immediately.
Advantage is that the client receives the new data as soon as it is available, and does not have to have to wait until the next client poll interval, resulting in a smoother user experience.
Downside is that it esentially ties up at least one PHP process per logged-in webinterface user, just for the polling.

OK, thanks for the explanation. Since even I had heard of the term long
polling, I guess this must be pretty common :-)

That said, I think in many cases buildroot-based systems will be serving just
one or two clients in parallel (at least that was the case for all the projects that I have worked on), so I still think it's better to set the default at 5 (which seems to be the default in the .conf file provided by the package as well).

[snip]

Quoted 23 lines

Quoted 23 lines
Quoted 23 lines
Quoted 1 line
There's also a php-fpm.service that you can install for systemd.
Yes, I noticed that before submitting the patch. But I never had much luck with systemd on buildroot.
The .service file generated by the PHP build did not work as-is when I tried it this morning.
==
Konsole output [Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target
[Service]
Type=simple
PIDFile=/var/run/php-fpm.pid ExecStart=${exec_prefix}/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
[Install]
WantedBy=multi-user.target
==

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
First problem was that systemd didn't like the ${exec_prefix}
That should probably have been substituted away by the conf.in -> conf
conversion...
Also seems to happen when compiling PHP outside of buildroot.

Of course, what I meant was that there's something wrong with how the PHP build
system handles that file. Which is really weird, because it follows exactly the same pattern as @localstatedir@ -> /var/run one line higher. Ah, now I see: we provide --localstatedir explicitly to configure, while sbindir is at its default.

In the init.d fragment they added exec_prefix=@exec_prefix@ to handle this.

Quoted 28 lines

==
max at lynx:/tmp/p/php-5.6.8/sapi/fpm$ cat php-fpm.service [Unit]
Description=The PHP FastCGI Process Manager After=syslog.target network.target
[Service]
Type=simple
PIDFile=${prefix}/var/run/php-fpm.pid ExecStart=${exec_prefix}/sbin/php-fpm --nodaemonize --fpm-config ${prefix}/etc/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
[Install]
WantedBy=multi-user.target
max at lynx:/tmp/p/php-5.6.8/sapi/fpm$ cat php-fpm.service.in [Unit]
Description=The PHP FastCGI Process Manager After=syslog.target network.target
[Service]
Type=@php_fpm_systemd@
PIDFile=@localstatedir@/run/php-fpm.pid
ExecStart=@sbindir@/php-fpm --nodaemonize --fpm-config @sysconfdir@/php-fpm.conf ExecReload=/bin/kill -USR2 $MAINPID

Quoted 8 lines

[Install]
WantedBy=multi-user.target
==
Is that a bug in PHP, or does systemd support variables in .service descriptions like this, and is the real problem perhaps that we are failing to set exec_prefix in some kind of global systemd environment file?

I don't think systemd supports that. Setting it in a global environment file
wouldn't work (it works for us, but not for the generic systemd use case) because every service could be installed into a different directory (like e.g. on NixOS).

So there are two options:

- Add execdir to the environment, i.e. add
Environment="exec_prefix=@exec_prefix@"

- Replace @sbindir@ with @EXPANDED_SBINDIR at .

Both options are upstreamable. I think the second one is the best one. For
upstream it should be done for the other variables as well of course (localstatedir, sysconfdir).

BTW, you should probably split the patch into two patches, one to install the
startup script and another one to install the config file, since both are rather independent of each other.

Regards,
Arnout

Quoted 8 lines

Yours sincerely,
Floris Bos

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F