https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291293
Bug ID: 291293
Summary: FreeBSD 15.0 choking on large file PHP uploads
Product: Base System
Version: 15.0-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Trying to uplaod max 1400 line file and here is my talk with Google Gemini:
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/serendipity/serendipity_admin.php?serendipity[adminModule]=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 FreeSD 15 as in FreeBSD is subnit files
1000+ plus but now they have to broken into 200 to 100 line pieces
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 LimitsIf the script
is processing a large file or performing many database operations, it might be
timing out.FileDirectiveAction$\texttt{php.ini}$max_execution_timeIncrease from
the default (e.g., $\texttt{30}$ seconds) to $\texttt{300}$ or
$\texttt{600}$.$\texttt{php.ini}$max_input_timeIncrease to match or exceed
$\texttt{max\_execution\_time}$.$\texttt{php.ini}$memory_limitIncrease (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:Nginxfastcgi_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 FixThe 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. No issue in FBsd14.3 downwards
--
You are receiving this mail because:
You are the assignee for the bug.
