Just today chatting with Google Gemini Question:
Freebsd 15 php 8.4 seeing [error] 76006#100398: *380 upstream prematurely closed connection while reading response header from upstream, client: 162.157.247.67, server: www.nk.ca, request: "POST /~doctor/blog/serendipity/serendipity_admin.php? HTTP/3.0", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", referrer: "https://www.nk.ca/~doctor/blog/sere...nModule]=entries&serendipity[adminAction]=new" The involved nginx configuration is location ~ ^/~(.+?)(/.+\.php)$ {
alias /usr/home/$1/html$2;
autoindex on;
index index.php index.phtml index.shtml index.html index.htm;
# default fastcgi settings
include /usr/local/etc/nginx/fastcgi_params;
# A bit of added security -- not full proof, but can help
fastcgi_split_path_info ^(.+\.php)(/.+)$;
# NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
fastcgi_param SCRIPT_FILENAME /usr/home/$1/html/$2;
fastcgi_read_timeout 300s;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
}[29-Nov-2025 12:58:29.956813] NOTICE: pid 71140, fpm_children_bury(), line 300: [pool www] child 71152 exited with code 0 after 6610.539839 seconds from start
[29-Nov-2025 12:58:29.956833] DEBUG: pid 71140, fpm_children_make(), line 449: blocking signals before child birth
[29-Nov-2025 12:58:29.960240] DEBUG: pid 71140, fpm_children_make(), line 473: unblocking signals, child born
[29-Nov-2025 12:58:29.960281] NOTICE: pid 71140, fpm_children_make(), line 479: [pool www] child 34501 started
[29-Nov-2025 13:58:30.198151] DEBUG: pid 71140, fpm_got_signal(), line 81: received SIGCHLD
[29-Nov-2025 13:58:30.208799] DEBUG: pid 71140, fpm_event_loop(), line 426: event module triggered 1 events
[29-Nov-2025 13:58:30.208863] NOTICE: pid 71140, fpm_children_bury(), line 300: [pool www] child 71155 exited with code 0 after 10210.789118 seconds from start
[29-Nov-2025 13:58:30.208882] DEBUG: pid 71140, fpm_children_make(), line 449: blocking signals before child birth
[29-Nov-2025 13:58:30.211568] DEBUG: pid 71140, fpm_children_make(), line 473: unblocking signals, child born
[29-Nov-2025 13:58:30.211608] NOTICE: pid 71140, fpm_children_make(), line 479: [pool www] child 76069 started
The database in question is using mariadb php-fpm logs show [
Looks the a problem originating in FreeBSD 15 as in FreeBSD is submit files 1000+ plus but now they have to broken into 200 to 100 line pieces Google Gemini said
The error **`upstream prematurely closed connection while reading response header from upstream`** indicates that the **PHP-FPM** process stopped or terminated before it could finish sending the HTTP response back to Nginx.
Based on your provided logs and context, the issue is **most likely caused by PHP script execution limits, memory issues, or a fundamental difference in how I/O (input/output) or process handling is managed in FreeBSD 15 compared to previous versions.**
Here is what needs to be fixed and investigated, categorized by component:
-----
## 1\.
PHP-FPM / System Limits (Primary Suspect)
The Nginx log error combined with your observation about having to break files into smaller pieces strongly suggests the PHP script is running into a resource limit or an I/O buffer issue specific to FreeBSD 15/PHP 8.4 combination.
### A. Increase PHP Execution Limits
If the script is processing a large file or performing many database operations, it might be timing out.
| File | Directive | Action |
| :--- | :--- | :--- |
| $\texttt{php.ini}$ | **`max_execution_time`** | Increase from the default (e.g., $\texttt{30}$ seconds) to $\texttt{300}$ or $\texttt{600}$. |
| $\texttt{php.ini}$ | **`max_input_time`** | Increase to match or exceed $\texttt{max\_execution\_time}$. |
| $\texttt{php.ini}$ | **`memory_limit`** | Increase (e.g., from $\texttt{128M}$ to $\texttt{512M}$) to ensure the script doesn't run out of memory during a large operation. |
### B. Increase Nginx Timeouts (Already Done, but Confirm)
You have already set the Nginx timeout to $\texttt{300s}$, which is good, but it's worth reviewing:
```nginx
fastcgi_read_timeout 300s;
```
If the PHP script is still timing out, you might need to increase this *further*, but the root cause is still likely in PHP-FPM.
### C. Check FreeBSD 15 Limits (The I/O/File Submission Issue)
Your comment about having to break files into smaller pieces points to a **system-level I/O or buffer constraint**.
* **Temporary Buffers:** FreeBSD 15 or a specific security patch may have reduced the default buffer size for socket I/O, which could be causing a process to block or close prematurely when large amounts of data are submitted (like a large POST request).
* **File Descriptors:** Check the per-user and system-wide file descriptor limits (using $\texttt{ulimit -n}$ or $\texttt{sysctl}$ settings) for the user running PHP-FPM.
-----
## 2\.
Database (MariaDB)
If the PHP script is crashing, it's often due to a large, long-running database query.
* **MariaDB/MySQL Timeouts:** Check the MariaDB configuration for **`wait_timeout`** and **`interactive_timeout`**. If these are short (e.g., $\texttt{30}$ seconds), the database connection may be dropping while the PHP script is waiting for a large operation.
* **Slow Query Log:** Enable the MariaDB slow query log to confirm if the script is hanging on a complex or slow query.
-----
## 3\.
PHP-FPM Configuration (`www.conf` Pool)
Ensure the PHP-FPM pool is not running out of resources or being too aggressive with process management.
* **`max_children`:** Ensure you have enough child processes available. If the server is very busy, all children may be occupied, leading to connection failures.
* **`request_terminate_timeout`:** Check this setting in your $\texttt{php-fpm.conf}$ or pool configuration file. If this is set (e.g., to $\texttt{30s}$), it will forcefully kill the PHP-FPM worker after that time, which would definitely cause the Nginx error. **If it's set, increase it or set it to $\texttt{0}$ (off) to rely on the $\texttt{max\_execution\_time}$ in $\texttt{php.ini}$.**
-----
### Summary of the Likely Fix
The most direct solution is to **increase the `max_execution_time` and `memory_limit` in $\texttt{php.ini}$** and ensure that $\texttt{request\_terminate\_timeout}$ in your PHP-FPM pool configuration is either very long or disabled ($\texttt{0}$).
Given your I/O observation, if the standard PHP limits don't resolve it, the problem is a more complex interaction with FreeBSD 15's low-level networking/I/O buffers that might require system $\texttt{sysctl}$ adjustments, which often involves consulting the FreeBSD forums or documentation for known issues with large POST submissions. Never had this problem in FreeBSD 14.3 or celow
Freebsd 15 php 8.4 seeing [error] 76006#100398: *380 upstream prematurely closed connection while reading response header from upstream, client: 162.157.247.67, server: www.nk.ca, request: "POST /~doctor/blog/serendipity/serendipity_admin.php? HTTP/3.0", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", referrer: "https://www.nk.ca/~doctor/blog/sere...nModule]=entries&serendipity[adminAction]=new" The involved nginx configuration is location ~ ^/~(.+?)(/.+\.php)$ {
alias /usr/home/$1/html$2;
autoindex on;
index index.php index.phtml index.shtml index.html index.htm;
# default fastcgi settings
include /usr/local/etc/nginx/fastcgi_params;
# A bit of added security -- not full proof, but can help
fastcgi_split_path_info ^(.+\.php)(/.+)$;
# NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
fastcgi_param SCRIPT_FILENAME /usr/home/$1/html/$2;
fastcgi_read_timeout 300s;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
}[29-Nov-2025 12:58:29.956813] NOTICE: pid 71140, fpm_children_bury(), line 300: [pool www] child 71152 exited with code 0 after 6610.539839 seconds from start
[29-Nov-2025 12:58:29.956833] DEBUG: pid 71140, fpm_children_make(), line 449: blocking signals before child birth
[29-Nov-2025 12:58:29.960240] DEBUG: pid 71140, fpm_children_make(), line 473: unblocking signals, child born
[29-Nov-2025 12:58:29.960281] NOTICE: pid 71140, fpm_children_make(), line 479: [pool www] child 34501 started
[29-Nov-2025 13:58:30.198151] DEBUG: pid 71140, fpm_got_signal(), line 81: received SIGCHLD
[29-Nov-2025 13:58:30.208799] DEBUG: pid 71140, fpm_event_loop(), line 426: event module triggered 1 events
[29-Nov-2025 13:58:30.208863] NOTICE: pid 71140, fpm_children_bury(), line 300: [pool www] child 71155 exited with code 0 after 10210.789118 seconds from start
[29-Nov-2025 13:58:30.208882] DEBUG: pid 71140, fpm_children_make(), line 449: blocking signals before child birth
[29-Nov-2025 13:58:30.211568] DEBUG: pid 71140, fpm_children_make(), line 473: unblocking signals, child born
[29-Nov-2025 13:58:30.211608] NOTICE: pid 71140, fpm_children_make(), line 479: [pool www] child 76069 started
The database in question is using mariadb php-fpm logs show [
Looks the a problem originating in FreeBSD 15 as in FreeBSD is submit files 1000+ plus but now they have to broken into 200 to 100 line pieces Google Gemini said
The error **`upstream prematurely closed connection while reading response header from upstream`** indicates that the **PHP-FPM** process stopped or terminated before it could finish sending the HTTP response back to Nginx.
Based on your provided logs and context, the issue is **most likely caused by PHP script execution limits, memory issues, or a fundamental difference in how I/O (input/output) or process handling is managed in FreeBSD 15 compared to previous versions.**
Here is what needs to be fixed and investigated, categorized by component:
-----
## 1\.
PHP-FPM / System Limits (Primary Suspect)The Nginx log error combined with your observation about having to break files into smaller pieces strongly suggests the PHP script is running into a resource limit or an I/O buffer issue specific to FreeBSD 15/PHP 8.4 combination.
### A. Increase PHP Execution Limits
If the script is processing a large file or performing many database operations, it might be timing out.
| File | Directive | Action |
| :--- | :--- | :--- |
| $\texttt{php.ini}$ | **`max_execution_time`** | Increase from the default (e.g., $\texttt{30}$ seconds) to $\texttt{300}$ or $\texttt{600}$. |
| $\texttt{php.ini}$ | **`max_input_time`** | Increase to match or exceed $\texttt{max\_execution\_time}$. |
| $\texttt{php.ini}$ | **`memory_limit`** | Increase (e.g., from $\texttt{128M}$ to $\texttt{512M}$) to ensure the script doesn't run out of memory during a large operation. |
### B. Increase Nginx Timeouts (Already Done, but Confirm)
You have already set the Nginx timeout to $\texttt{300s}$, which is good, but it's worth reviewing:
```nginx
fastcgi_read_timeout 300s;
```
If the PHP script is still timing out, you might need to increase this *further*, but the root cause is still likely in PHP-FPM.
### C. Check FreeBSD 15 Limits (The I/O/File Submission Issue)
Your comment about having to break files into smaller pieces points to a **system-level I/O or buffer constraint**.
* **Temporary Buffers:** FreeBSD 15 or a specific security patch may have reduced the default buffer size for socket I/O, which could be causing a process to block or close prematurely when large amounts of data are submitted (like a large POST request).
* **File Descriptors:** Check the per-user and system-wide file descriptor limits (using $\texttt{ulimit -n}$ or $\texttt{sysctl}$ settings) for the user running PHP-FPM.
-----
## 2\.
Database (MariaDB)If the PHP script is crashing, it's often due to a large, long-running database query.
* **MariaDB/MySQL Timeouts:** Check the MariaDB configuration for **`wait_timeout`** and **`interactive_timeout`**. If these are short (e.g., $\texttt{30}$ seconds), the database connection may be dropping while the PHP script is waiting for a large operation.
* **Slow Query Log:** Enable the MariaDB slow query log to confirm if the script is hanging on a complex or slow query.
-----
## 3\.
PHP-FPM Configuration (`www.conf` Pool)Ensure the PHP-FPM pool is not running out of resources or being too aggressive with process management.
* **`max_children`:** Ensure you have enough child processes available. If the server is very busy, all children may be occupied, leading to connection failures.
* **`request_terminate_timeout`:** Check this setting in your $\texttt{php-fpm.conf}$ or pool configuration file. If this is set (e.g., to $\texttt{30s}$), it will forcefully kill the PHP-FPM worker after that time, which would definitely cause the Nginx error. **If it's set, increase it or set it to $\texttt{0}$ (off) to rely on the $\texttt{max\_execution\_time}$ in $\texttt{php.ini}$.**
-----
### Summary of the Likely Fix
The most direct solution is to **increase the `max_execution_time` and `memory_limit` in $\texttt{php.ini}$** and ensure that $\texttt{request\_terminate\_timeout}$ in your PHP-FPM pool configuration is either very long or disabled ($\texttt{0}$).
Given your I/O observation, if the standard PHP limits don't resolve it, the problem is a more complex interaction with FreeBSD 15's low-level networking/I/O buffers that might require system $\texttt{sysctl}$ adjustments, which often involves consulting the FreeBSD forums or documentation for known issues with large POST submissions. Never had this problem in FreeBSD 14.3 or celow
