PHP file upload limit change doesn't take effect until reboot

Keywords: LAMP/MAMP/WAMP - AWS - Technical issue - Other
bnsupport ID: 1925f0ce-b103-8c6d-9e32-9dfe362c01c5
Description:
Following the suggestions in the “Modify The PHP File Upload Limit” page, I change the post_max_size and upload_max_filesize settings. Then I restart the services using the following command:

sudo /opt/bitnami/ctlscript.sh restart

This does nothing. Then I try to, first, stop, and then start. Again, doesn’t work.

The only way it works if I reboot the instance from the Lightsail panel. Why is this?

I’m testing this on an instance that I’ve created today. So it’s clean. What’s the problem? Can’t I make changes without rebooting the instance?

Hi @akinoreh,

Thanks for using Bitnami. It is weird restarting the services isn’t working. I checked the bnsupport bundle you provided and I found Bitnami services aren’t running

-----------------------------------
Get the ctlscript status
-----------------------------------
Running: ./ctlscript.sh status
In: /opt/bitnami

Output:

apache not running
mysql not running
php-fpm not running

Can you run the next commands to try to debug it?

sudo /opt/bitnami/ctlscript.sh restart
sudo gonit status
sudo systemctl status bitnami.service

Apart from the above, I don’t see any new value in the php.ini file for the post_max_size or the upload_max_filesize parameters. To which value are you setting it?

This is weird. I had a similar reply to another question: LimitRequestBody returns 200 OK. I just checked and the server is working fine. You (both) seem to be getting wrong information. Why is that?

I currently have 5 instances, and just to make sure, I checked them too. All 5 is working fine, but one of them outputs ____ not running as you mentioned, but the server is running fine. I don’t know what to make of this. And this server isn’t the one that I mentioned in the question.

Let’s say that there’s an error on my part. The only thing that I can think of is that I ran the support tool on the wrong instance. Is there a way to confirm this? Can I find the generated support id in some dir/file?

Okay, so I tried to inspect the /opt/bitnami/bnsupport dir, and I found a folder there: original-data. It seems to be a snapshot of some configuration files. I suppose those files are transferred to you.

I have original-data folder in 3 of my instances. I don’t remember running the tool on other two. I thought about comparing the dates of the files/folders, but they don’t seem to be reliable. The files in the server-in-question date back to february even though I created the instance this week. The others date back to mid 2020.

So what do we do now? Can I delete the original-data folder and run the support tool again?

Sigh. I’ve removed original-data folders from all instances, and ran the support tool again in the temp/test instance. Once it finished, it output this id:

4bee5ae6-039d-f99d-28d0-61358d700e39

but now I don’t see any original-data folder in the /opt/bitnami/bnsupport dir.

Thinking there might be something wrong with the tool, I’ve decided to update it. The previous version might have been 0.9.3. After update, I believe it’s 0.9.9. Ran the tool again. It warned me about some issues:

? Apache: Found possible issues
✓ Connectivity: No issues found
? Resources: Found possible issues
✓ Mysql: No issues found
✓ Php: No issues found

[Apache]
... AH01071: Got error 'PHP message: PHP Warning: POST Content-Length of 2440971 bytes exceeds the limit of 2097152 bytes in Unknown on line 0', referer: http://3.67.74.111/single.php

[Resources]
total used free shared buff/cache available Mem: 478 295 61 5 121 164 Swap: 634 293 341

I don’t suppose they’re related to the problem at hand. Then gave me an id:

af884d22-af8f-07b4-24cc-a1c0f53f5380

I still don’t see any original-data folder in the /opt/bitnami/bnsupport dir. So I’m not sure if you get any report.

Hi @akinoreh,

Thanks for your messages. The original-data folder was created at some point for the bnsupport tool to find changes in the config files. It is created when we build the image as a snapshot of the initial status, and not generated by the bnsupport tool. It is not possible to recover it, but we will try to fix your issue without using that information.

The bnsupport tool will get only the current information in your instance, without us knowing the original status of some config files. When I mentioned in my previous message that I didn’t see any change in php.ini it was because the information in the original-data/php.ini file and the php.ini in use on your instance when the bnsupport bundle was created was exactly the same.

I see the changes in the new code though, then I understand you were running the tool in a different machine or you did the changes after running the tool for the first time. Anyways, I see some weird data in the tool, as the ctlscript.sh is not detecting the services running, but there are some processes in the system related to Bitnami. Did you have any chance to run the commands I asked for in my previous message?

Keywords: LAMP/MAMP/WAMP - AWS - Technical issue - Other
bnsupport ID: 19f709d3-925c-05a3-9674-6da7e3403799
Description:
I’ve set LimitRequestBody 2097152 in httpd.conf along with the appropriate changes in the php.ini. When I upload a file larger than 2MB, I get a 200 OK response and can see the form page. Shouldn’t I be getting a 413 Request Entity Too Large error?

I’m not sure what the support id provides you or if it’s enough to inspect the problem, but I’ve setup a test page where one can upload a file and see the result. I can share the URL if it’ll help/speed up the process.

Hello @akinoreh,

I cannot see changes in your php.ini. Could you try to update these values?

post_max_size
upload_max_size 

I hope it helps

Really? I just checked the /opt/bitnami/php/etc/php.ini, and I have the following in the specified lines:

695 post_max_size = 2M
848 upload_max_filesize = 2M

and also in /opt/bitnami/apache/conf/httpd.conf:

535 LimitRequestBody 2097152

This is the test page: http://3.67.74.111/single.php. If I upload a file less than 2 MB, I can see page/files. If I upload a file greater than 2 MB, I can’t see the file (in $_FILES) as expected, but I can see the page. The server returns 200 OK. I’d expect the server to return 413 Request Entity Too Large.

It seems there might be some issues. I didn’t really inspect how the support tool works. Just ran it, got the id, and posted it. Now I realize that it takes a snapshot of some configuration files.

So if you can’t see the modified php.ini file, that might be because the files/report you’ve received are not up to date. Although I dediced to post a question here after I made sure that there’s a problem with the file upload. So the report should’ve been up to date anyway.

Regardless, the current configuration is exactly as I mentioned in my previous reply. Three changes in two files.

Either LimitRequestBody doesn’t work as expected, or I have wrong assumptions about the ways LimitRequestBody directive works.

I can run the support tool again if it’ll help.

@gongomgra Okay, recap. I might have ran the tool (the first time) in the wrong instance because of PuTTY misconfiguration. So the initial report you got is irrelevant to this situation. I believe this covers the missing changes in the php.ini and the service not running statuses.

I did not run the commands you’ve mentioned because when I checked, the instance in question did not produce service not running output. However, another instance did. I restarted the services on the other instance, and it’s fixed.

Now, I’m checking the instance in question again, and when I checked the status, it says the services are not running, but the server is running. I mean, I can visit the /single.php page and interact with it just fine.

Since my two questions/topics are merged, let’s list the problems again. I had two problems, but it seems there’s another one.

  1. sudo /opt/bitnami/ctlscript.sh status command says the services are not running, but the server is functioning fine. What’s with that?

  2. The changes I make to php.ini or httpd.conf do not take effect until I manually reboot the instance from the Lightsail panel. sudo /opt/bitnami/ctlscript.sh restart doesn’t seem to work.

  3. I want to prevent large file upload, and set a custom error document for 413 Request Entity Too Large error. In order to do that, I set/change the limits in the php and apache configuration files. Then check the result in the /single.php page. It doesn’t work. File upload fails, but I get a 200 OK response, not 413 Request Entity Too Large error. (I’ll be setting a custom error document after I make sure the 413 error works fine.)

Now, how do we solve these?

If it helps, I can create a new instance if this one seems not so clean anymore.

Again, the page I’m doing the upload checks is http://3.67.74.111/single.php, and the current configuration is exactly as I stated in a previous reply. I’ll refrain from making further changes by myself. So, what do I now?

Hi @akinoreh,

Thanks for the detailed information. Yes, we merged both tickets because they seems to be related to the same instance and to be similar issues (new php config not being properly detected by the services).

Taking a look at the list of issues, I think we should handle the ctlscript.sh issue first. Can you run the commands into this server? I think it is better using the current instance.

Allright. Ran them one by one, and noted the outputs.

user@ip:~$ sudo /opt/bitnami/ctlscript.sh status
apache not running
mysql not running
php-fpm not running

user@ip:~$ sudo /opt/bitnami/ctlscript.sh restart
Restarting services..
user@ip:~$ sudo /opt/bitnami/ctlscript.sh status
apache already running
mysql already running
php-fpm already running

user@ip:~$ sudo gonit status

Uptime                         91h0m46s
Last Check                     2021-06-02 09:54:15.681415366 +0000 UTC m=+327600.449126632
Next Check                     2021-06-02 09:56:15.681415366 +0000 UTC m=+327720.449126632
Pid                            1074
Pid File                       /var/run/gonit.pid
Control File                   /etc/gonit/gonitrc
Socket File                    /var/run/gonit.sock
Log File                       /var/log/gonit.log
Process 'apache'
  status                                        Running
  pid                                              5425
  uptime                                          3m34s
  monitoring status                           monitored

Process 'mysql'
  status                                        Running
  pid                                              5763
  uptime                                          3m34s
  monitoring status                           monitored

Process 'php-fpm'
  status                                        Running
  pid                                              5399
  uptime                                          3m34s
  monitoring status                           monitored

user@ip:~$ sudo systemctl status bitnami.service
● bitnami.service - LSB: bitnami init script
   Loaded: loaded (/etc/init.d/bitnami; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-06-02 09:51:29 UTC; 4min 20s ago
  Process: 5296 ExecStart=/etc/init.d/bitnami start (code=exited, status=0/SUCCESS)
    Tasks: 380 (limit: 558)
   Memory: 394.5M
   CGroup: /system.slice/bitnami.service
           ├─1074 /opt/bitnami/gonit/bin/gonit
           ├─5399 php-fpm: master process (/opt/bitnami/php/etc/php-fpm.conf)
           ├─5403 php-fpm: pool www
           ├─5404 php-fpm: pool www
           ├─5405 php-fpm: pool www
           ├─5406 php-fpm: pool www
           ├─5407 php-fpm: pool www
           ├─5408 php-fpm: pool www
           ├─5409 php-fpm: pool www
           ├─5410 php-fpm: pool www
           ├─5411 php-fpm: pool www
           ├─5412 php-fpm: pool www
           ├─5425 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5427 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5428 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           └─5763 /opt/bitnami/mysql/bin/mysqld --defaults-file=/opt/bitnami/mysql/conf/my.cnf --basedir=/opt/bitnami

Jun 02 09:51:21 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:21.032Z - info: Performing service start operation for
Jun 02 09:51:26 ip-__-__-__-__ bitnami[5296]: mysql 09:51:26.29 INFO  ==> mysql started
Jun 02 09:51:27 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:27.135Z - info: Starting gonit monitoring service
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:29.258Z - info: Start monitoring all services from gon
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/p
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/p
lines 1-30...skipping...
● bitnami.service - LSB: bitnami init script
   Loaded: loaded (/etc/init.d/bitnami; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-06-02 09:51:29 UTC; 4min 20s ago
  Process: 5296 ExecStart=/etc/init.d/bitnami start (code=exited, status=0/SUCCESS)
    Tasks: 380 (limit: 558)
   Memory: 394.5M
   CGroup: /system.slice/bitnami.service
           ├─1074 /opt/bitnami/gonit/bin/gonit
           ├─5399 php-fpm: master process (/opt/bitnami/php/etc/php-fpm.conf)
           ├─5403 php-fpm: pool www
           ├─5404 php-fpm: pool www
           ├─5405 php-fpm: pool www
           ├─5406 php-fpm: pool www
           ├─5407 php-fpm: pool www
           ├─5408 php-fpm: pool www
           ├─5409 php-fpm: pool www
           ├─5410 php-fpm: pool www
           ├─5411 php-fpm: pool www
           ├─5412 php-fpm: pool www
           ├─5425 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5427 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5428 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           └─5763 /opt/bitnami/mysql/bin/mysqld --defaults-file=/opt/bitnami/mysql/conf/my.cnf --basedir=/opt/bitnami/mysql --datadir=/b

Jun 02 09:51:21 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:21.032Z - info: Performing service start operation for mysql
Jun 02 09:51:26 ip-__-__-__-__ bitnami[5296]: mysql 09:51:26.29 INFO  ==> mysql started
Jun 02 09:51:27 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:27.135Z - info: Starting gonit monitoring service
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:29.258Z - info: Start monitoring all services from gonit
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/010_bitna
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/020_bitna
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/030_updat
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/040_bitna
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/050_clean
Jun 02 09:51:29 ip-__-__-__-__ systemd[1]: Started LSB: bitnami init script.
lines 2-3/34 (END)

Hi @akinoreh,

Thanks for the info. Yes, it seems gonit is properly monitoring the services. Can you do a new test for the PHP configuration? According to the latest bnsupport bundle you shared, you have set post_max_size = 2M in php.ini. Can you check it using the phpinfo.php file below? Please visit the http://YOUR_IP_ADDRESS/phpinfo.php URL when you have created the file

<?php
phpinfo();
?>

In my case:

  • original value

  • Then I set it to 2M and restart services. You can see the Apache processes were started at a different time after the restart command

  • New value

Can you try this on your side changing only the post_max_size PHP value? As your current value is 2M, check that you get first 2M and then the new value (let’s say 8M) after editing the file and restarting the service.

Can you also run the next command before and after editing the file to double-check the value is updated?

grep post_max_size /opt/bitnami/php/etc/php.ini

Sure. I’ve set the /phpinfo.php page and it’s public.

The current value of post_max_size is 2M. Changed it to 8M. And then restarted the services. I see the updated 8M in both phpinfo and grep output. Now this leads me to question myself :slight_smile:

I’ve created another instance. Modified php settings. Restarted only php-fpm. It seems to work. So can I assume for changes only in php settings, restarting the php is enough?

Earlier, I may have overgeneralized a specific problem. The changes to httpd.conf does not seem to take effect. I set the LimitRequestBody 2097152 on the second test instance. Restarted apache. Doesn’t work. Restarted all services. Doesn’t work. What I mean by “doesn’t work” is that the connection is not terminated when the file size is larger than the limit. The server waits for the whole upload. This is wasteful.

Then I rebooted the instance from the Lightsail panel. It didn’t work. Now, this is new. It still waits for the whole upload. Next, I restart the services after I rebooted the instance. Still doesn’t work.


Argh. I’m deleting both instances. Created a new one at 3.67.159.167.

I changed the php.ini and set the sizes to 2M. Restarted the php service. The change took effect immediately. When I upload a file that exceeds the limits, the $_FILES array is empty. The problem with this setup is that the server still waits for the whole upload.

So now I set the LimitRequestBody 2097152 in httpd.conf at the end of the file. This time I’m skipping restarting only the apache, and restart all services. Doesn’t work. It still waits for the whole file/upload. Next I reboot the instance. Still doesn’t work. OMG.

Okay, this is no longer about php configuration, so the topic title won’t make sense. LimitRequestBody simply doesn’t work. Apache

  • doesn’t terminate the connection when a file larger than the limit is uploaded
  • returns 200 OK along with the original page instead of 413 Request Entity Too Large and the appropriate error document

How do I make it work? I can’t be doing something wrong, because each time I’m using a brand new instance, right? So what’s wrong?

Hi @akinoreh,

Thanks for your message. I think we have fixed 2 out of 3 problems now, right? About the LimitRequestBody directive, it is an Apache directive. I can’t find it in the Apache configuration, but you mention you are adding it at the end of the httpd.conf file. Can you add it upper in the file? Try setting it under the comment below. I think that because you are defining it as a default global value, you may add it before any DocumentRoot or VirtualHost definition.

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

Please try to add it below the comment above and then restart the services.

Regards,
Gonzalo

Added the directive at the place you suggested:

<Directory />
    AllowOverride none
    Require all denied
</Directory>

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

LimitRequestBody 2097152

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/opt/bitnami/apache/htdocs"
<Directory "/opt/bitnami/apache/htdocs">

Restarted only apache, and it didn’t work. Restarted all services. Didn’t work. Rebooted the instance, and still, didn’t work.

Apache still waits for the whole file/upload to finish, and then return 200 OK.

On my local machine (using XAMPP), however, I get 413 Request Entity Too Large and the following when using the same setup (configurations and single.php):

Request Entity Too Large
The requested resource does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.
Apache/2.4.47 (Win64) OpenSSL/1.1.1k PHP/8.0.6 Server at localhost Port 80

I don’t mean any disrespect, but are we going to continue this single check/test daily? There’s no reason for me to do these tests (about LimitRequestBody). I’m using a fresh instance/LAMP to eliminate any user errors. While I may have done some mistakes with the php configuration (wrong instance report, etc.) I don’t think it’s the case with this one.

I suppose you (the bitnami team) can easily verify this issue by creating an instance on AWS Lightsail yourselves. If there’s an issue with the LAMP stack, this doesn’t just concern me (a single user). So I can’t make sense of the situation we’re in right now.

Also, in light of this issue, Modify The PHP File Upload Limit page might need to be updated. Following the suggestions in the page obviously doesn’t work.

If you guys can’t/won’t test an instance on AWS Lightsail yourselves for whatever reason, I can provide access to the instance in question if it’s going to speed up the process.

Hi @akinoreh,

Thanks for your message. In this community forum, and having into account the big number of replies we get daily, we do our best to reply all threads usually in a business day.

For the LimitRequestBody directive, I did a manual test in a fresh instance and it is working for me. I configured the php settings as shown below

upload_max_filesize = 1M
post_max_size = 2M

Note according to the official PHP docs, the post_max_size value should be larger than upload_max_filesize.

https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize

I also set the LimitRequestBody directive to the same value you used and into the same place, and it is working fine after restarting services.

To do a test, I uploaded a 5 MB file, and it is returning 413 error code as you can see in the next screenshot

Also in the Apache logs

MY_IP_ADDRESS - - [07/Jun/2021:08:26:12 +0000] "POST /upload.php HTTP/1.1" 413 631

After that, I tried to upload a 1 MB file, and it ended with a 200 ok code.

MY_IP_ADDRESS - - [07/Jun/2021:08:57:13 +0000] "POST /upload.php HTTP/1.1" 200 41

I followed the next guide for testing this. Can you test it on your side?

https://www.w3schools.com/php/php_file_upload.asp

This is really weird. I deleted the current instance and created a new one. Created screenshots to record the steps and modifications I make. The result is the same. I still don’t get the 413 error.

The screenshots and the files (htdocs, php.ini, httpd.conf) are in Google Drive. This is the link:

https://drive.google.com/drive/folders/1UqKRH4vfVnPV2Gm5kHNiWXdrapvCGNQi?usp=sharing

The test/upload page: http://3.67.91.60/upload.php

I’m stuck. If it works for you, and not for me, then what’s the difference/problem?