Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116689 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 2705 invoked from network); 20 Dec 2021 23:19:51 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 Dec 2021 23:19:51 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0D4D718053C for ; Mon, 20 Dec 2021 16:23:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 20 Dec 2021 16:23:24 -0800 (PST) Received: by mail-ua1-f50.google.com with SMTP id u40so20745240uad.1 for ; Mon, 20 Dec 2021 16:23:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VpMJcwMeOyNkJT2Io5ZKGEoDTNYumlIquAfeF0KJih4=; b=qoUkTIAn3S70MAkf/n9KHLFALrQOjNcTJN+ES9FIx7GkxnUKCj5GyT9MqjwmvRL0JD BFb9EhuMJlc7t+cJiHhSISO8gILvt0EZSi0urBItOejm0xfZjrJ0r85wt+EeDgoexEPq 7B4ezAuE8XM4ELr3eD6clvT7RmuFzFS2QcYqdS/9dApY5xNwCmoojQc4Z5AIUkF1WczK nt/Mp6ErfIN7AIvSkoaYQDI4iQYNf1bROEz1gpd7K4bS1uFOrgOw8AQzN4Jhrbv8T12g UZJsyaxQsXltlaSfRAgPWFGXan3hk2My3+Z8NSkIEIZTz0k9Fxq0vSCff0N6jMW3ABvh 6MDQ== X-Gm-Message-State: AOAM53211d8tTguT/5IgqI/k+jr+FYMj/25RkbeWPGWB8eMQWRP5Q3wD DqK+fgo/S3RMKm8FCzL+8BP5OnIgpo4F2o4o24XuR5fc9Kk= X-Google-Smtp-Source: ABdhPJxfDR6ZK3oRqXgvMGyZER/d5PHfyw8INE6zw+H9iV/3nxYNaHn7xEPAbvWLcP1iR+uqxmhNW6NHnnZoB766DYw= X-Received: by 2002:a67:e45a:: with SMTP id n26mr331792vsm.16.1640046203625; Mon, 20 Dec 2021 16:23:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 21 Dec 2021 00:23:12 +0000 Message-ID: To: Derick Rethans Cc: PHP Developers Mailing List Content-Type: multipart/alternative; boundary="00000000000061e3d605d39d0324" Subject: Re: PHP-FPM process management woes From: bukka@php.net (Jakub Zelenka) --00000000000061e3d605d39d0324 Content-Type: text/plain; charset="UTF-8" Hi, On Mon, Dec 20, 2021 at 6:41 PM Derick Rethans wrote: > Literature since at least 2006 (Sara's Extending and Embedding PHP > book), as well as numerous presentations that I have seen and given, and > including the online PHP Internals Book > ( > https://www.phpinternalsbook.com/php7/extensions_design/php_lifecycle.html), > > always expected that the MINIT (and MSHUTDOWN) functions are called once > per worker process. However, PHP-FPM does not do that. It only calls > extension's MINITs once in the main control process, but it *does* call > an MSHUTDOWN for each worker process. > In the past, this has already caused an issue where I couldn't create a > monitoring thread in MINIT, and then wait for it to end in MSHUTDOWN, as > MSHUTDOWN would wait on the same thread in each worker process, although > only one was created in MINIT. > > The way how PHP-FPM handles this breaks the generally assumed "one > MINIT, one MSHUTDOWN call" per process approach. > Yeah this is a bit unfortunate asymetry. It has got some slight advantages like in case of preloading that is done just once instead of on each child init. However there are most likely more disadvantages like the ones above and also the fact that MINIT is often run under the root so it's not ideal from the security point of view - especially when running 3rd party extensions. > In particular, in the case of Xdebug bug #2051 it creates a problem with > the following set-up: > > 1. php.ini has a `xdebug.mode=off` > 2. the pool configuration has a `php_admin_value[xdebug.mode] = debug` > directive > > So this is actually mainly about the fact that fpm_php_apply_defines runs after the MINIT. You might be able to tweak this but not sure if it completely fixes the issue as there's another to way overwrite INI that happens during the request. It is using FCGI env PHP_ADMIN_VALUE (see fastcgi_ini_parser usage) so you might need to handle this case in your code anyway. Basically you can't rely on the fact that INI stays the same so you will probably have to add some logic to your RINIT to handle this. > > My suggestion for a fix would be to emulate what Apache always did: > > One MINIT/MSHUTDOWN in the main control process (I think it needed that > to be able to implement php_admin_value and php_value), and then > additionally also in each worker process. > As I said above, it won't probably fully fix your problem but if you still want to try to tackle it and move the MINIT, the way that I would do it is to try to separate the whole sapi init logic and call it from the child init as the first thing. If you want to experiment with using php_admin_value before the module minit, then it might be worth to try put fpm_php_init_child (or just the defines) to sapi startup callback before calling php_module_startup so the main INIs are loads but it might be a bit tricky to get worker pool config - it might need some extra globals maybe for it. But not sure if that's gonna work (e.g. if the main INI files are loaded at the sapi startup stage) and what will be impact on extensions. I'd probably have to check it more and try it. Think it's also something that could happen in master branch only as it's changing some fundamental bits in FPM... Regards Jakub --00000000000061e3d605d39d0324--