[Buildroot] [PATCH] php: fpm sapi: install startup script

[Arnout Vandecappelle]

On 05/01/15 12:42, Floris Bos wrote:
> On 05/01/2015 01:20 AM, Arnout Vandecappelle wrote:
[snip]
>>>>> +# 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.
> 
> 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]
>>>>   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}
>>   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.


> 
> ==
> 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?

 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



> 
> 
> Yours sincerely,
> 
> Floris Bos
> 
> 
> 


-- 
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