From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnout Vandecappelle Date: Fri, 01 May 2015 14:48:03 +0200 Subject: [Buildroot] [PATCH] php: fpm sapi: install startup script In-Reply-To: <554358A1.6030006@je-eigen-domein.nl> References: <1430422567-14903-1-git-send-email-bos@je-eigen-domein.nl> <5542901D.30403@mind.be> <5542A99C.5060409@je-eigen-domein.nl> <5542B8A8.20100@mind.be> <554358A1.6030006@je-eigen-domein.nl> Message-ID: <55437603.1020007@mind.be> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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