Cannot upload more than 20 items despite max_file_uploads being set
Closed this issue · 6 comments
Server Software
(You can get all these stats from http://<your site>/system_info)
shimmie: "2.11.0-alpha-20240221-3f064c3"
schema: 21
php: "8.2.7"
db: "pgsql PostgreSQL 15.5 on x86_64-pc-linux-musl, compiled by gcc (Alpine 13.2.1_git20231014) 13.2.1 20231014, 64-bit"
os: "Linux e13cd6e4d8ee 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64"
server: "Unit/1.31.1"
Client Software (please complete the following information)
- Device: desktop
- Browser: Firefox v122.0
What steps trigger this bug
- in board config, set max uploads to e.g. 300
- in php.ini, set/add max_file_uploads = 1000
- stop+start web server
- try to upload more than 20 items
What did you expect to happen?
More than 20 items should be uploaded. In case of trying to upload already-existing items, more than the first 20 items should be checked.
What actually happened?
Exactly 20 items are uploaded. If trying to upload items which already exist, only the first 20 items are checked and reported with "already exist"-errors.
webserver container logs only show the following then trying to upload more than 20 files:
2024/02/21 11:13:19 [notice] 95#95 [unit] #18: php message: PHP Warning: Maximum number of allowable file uploads has been exceeded in Unknown on line 0
It's as if max_file_uploads in php.ini has no effect - could there be any other php extension which comes with its own upload limit?
I wonder if the PHP system-level setting is taking effect properly - what shows up on the Board Config page under Upload?
(I also wonder what you mean by php.ini - max_file_uploads is "a php.ini setting", but when running with Unit, PHP settings need to be set in Unit's config.json rather than a literal file named php.ini)
When you started/stopped the web server, are you sure PHP was restarted? For me, I need to restart the php8.1-fpm service to change the upload limits.
#1059 should make this configurable via docker variables, same as the max file size
I initially only changed the php.ini directly - added the new environment variable to my docker-compose and it works now, thank you.
Just to clarify since I'm not really familiar with Unit:
but when running with Unit, PHP settings need to be set in Unit's config.json rather than a literal file named php.ini)
you are referring to /var/lib/unit/conf.json, right? So any php-settings I might change should rather be changed in that file - can I just mount my own conf.json to overwrite /var/lib/unit/conf.json and change settings that way, or should this rather be done with a custom built image? And does this affect just a subset of PHP settings or does it apply to "changing PHP config in general"?
So at the moment there isn't a way of setting system-level PHP variables inside docker that I'm completely happy with D:
The current process is that each time the container starts, it will look at /app/.docker/entrypoint.d/config.json.tmpl, check a few specific defined-in-advance environment variables (eg MAX_FILE_UPLOADS), and generate config.json from that
It'd be nice to have something more flexible, but also, I don't want to be tied to Unit as a web server (ie, I don't want "the way to customise php.ini settings is to mount your own Unit config file", because that will break if we ever stop using Unit) -- the "set environment variables on the container, and the container startup scripts will translate that into whatever web server config file is needed" approach is what allowed us to switch from the PHP built-in webserver to unit already...
Maaaaybe something like "Setting any PHP_xxx environment variable will be automatically translated into the xxx php.ini setting", to be both flexible and generic?
Mostly I would prefer if the web server inside the container didn't need any end-user configuration in the first place >.> I keep thinking about removing the configurations and just hard-coding the web server limits to eg 10GB / 1000 files (and then shimmie itself can apply whatever limits the admin chooses via the GUI), but something feels wrong about that and I can't put my finger on it...
So #1066 redoes this process to be a bit more reliable with the possibility of more general configuration-ing in the future. I'm still not really happy with it, but I don't want to try and design a whole big flexible solution for the sake of two variables (both of which I'd prefer to totally get rid of)... If there are more webserver-level config options which need to exist, feel free to open a new task and we can consider how to deal with those ^^