Fyi - I too am having issues with client_body_max_size in a docker container, and in fact I just signed up for this mailing list just because of that. Restarting docker seems to have no effect for me. I will send a detailed email about the issue if I'm not able to figure it out myself soon. Regards
On Sun, Feb 6, 2022 at 2:53 PM Francis Daly <fran...@daoine.org> wrote: > On Fri, Feb 04, 2022 at 06:33:08PM -0500, marioja2 wrote: > > Hi there, > > There's lots of information here, and I'm not sure what specific parts > relate to an nginx issue. > > I don't have a full answer, but there are some suggestions below that > might help point at where the problem and fix might be. > > > I am running nginx in a container created with a docker-compose yaml > file. > > Here is a sample docker-compose.yml and environment file: > > > > > https://github.com/marioja/Mailu/tree/test-mailu/test-mailu-docker-compose > . > > I don't see "this is content of the nginx.conf file" on that page. I > also don't see "here is where nginx is started". > > > the configuration entries in the > > /etc/nginx/http.d/rainloop.conf configuration file created when the > rainloop > > image starts from the webmails/rainloop/config/nginx-rainloop.conf in the > > github branch previously mentioned is not recognized by nginx when the > > webmail container (using the rainloop image) is started by > docker-compose up > > -d. However, if I restart the webmail container using docker-compose > > restart webmail then the instructions in that rainloop.conf are then > > recognized by nginx. > > If you can find the place that starts nginx, perhaps adding a call to > nginx with all of the same arguments plus "-T", and catching the stdout > and stderr of that somewhere, will help? > > That should show what config files, with what content, this instance of > nginx is reading. > > If that output differs between the "up -d" and the "restart webmail" > calls, that might point at the next place to investigate. > > > I tried to use nginx-debug with error_log set to debug > > but the output I get is not understandable and does not refer to any > config > > file path or parsing. > > The nginx debug log can be a bit overwhelming -- there's lots in it, > and it is not always immediately clear why what is in it, is in it. > > But people who know what to look for, and what is "normal" in it, may > be able to interpret it for you. > > Generally, you want something of the form: > > I make *this* request > I get *this* response > I want *that* response instead > > ideally with enough information to allow someone else to repeat what > you are doing. > > And if the log file is especially big, it may be better to host it > somewhere and provide a link to it. > > You can edit the file to hide "private" information -- but if you do > change things, please change them consistently. Best would be to build > a test system with no private information, and provide the full logs > for that system that shows the same problem. > > > The reason I am asking this in the nginx mailing list is because I have > > exhausted all of the tests that can gather information from the container > > side and I am wondering if there is anything that you guys can thing that > > could explain this. Here is the directory structure of the files in the > > container where nginx is running before starting as a result of the > > docker-compose up -d: > > When nginx starts, it reads one configuration file. > > "nginx -T" should show the contents of that, plus anything "include"'d > from it, that nginx sees. > > It looks like your starting file might be from > > https://git.alpinelinux.org/aports/tree/main/nginx/nginx.conf > > with the error_log line (line 12) set to debug; and then your include'd > file re-sets it to "warn" and changes client_max_body_size, within that > server{} block. > > From what you describe, it sounds like the include'd file may not be > present when nginx first starts? Are there any requests that you make > that do succeed, before the one that fails? > > Where are you reading the error log? From /var/log/nginx/error.log, > or from stderr from the docker command? It might make a difference, > if two error_log directives are present. > > > This is the content of the rainloop.conf in the webmail container at > > runtime: > > Is that "according to something that runs before nginx starts", or > something else? > > If files are being changed, the timing might matter. > > > # /dev/stdout (Default), <path>, off > > access_log off; > > > > # /dev/stderr (Default), <path>, debug, info, notice, warn, error, > crit, > > alert, emerg > > error_log /dev/stderr warn; > > When problems are happening, turning on logging can be useful to see > what the system thinks is happening. > > > # set maximum body size to configured limit > > client_max_body_size 58388608; > > That's about 55 MB. > > > Is there a way to tell nginx or nginx-debug to tell us what is going on? > > Don't turn off the logging. > > > The error that occurs after docker-compse up -d is that a 5MB attachment > > posted to the webmail container fails. > > I'm guessing that's a HTTP 413 coming direct from nginx; not any message > from the fastcgi service; and not a HTTP 502 coming direct from nginx? > > The specific details might matter. > > (413 suggests that the "new" client_max_body_size was not used. 502 > suggests that php-fpm was not available. Another error might suggest > something else. nginx's error_log will usually indicate why it raised > an error response, at a suitable log level.) > > > That same 5MB attachment works after > > a docker-compose restart. The statement that does not appear to take > effect > > until the docker-compose restart is the client_max_body_size 58388608. > > Please note that there is a client_max_body_size 1m directive in the > > /etc/nginx/nginx.conf during both restart (docker-compose up and > > docker-compose restart). > > > > I have searched low and high for any information about this http.d > directory > > but I could not see anything. I am using nginx version 1.20.2 installed > > from alpinelinux apk command. > > Your nginx.conf line 103 might have "include /etc/nginx/http.d/*.conf;" > which reads the matching file contents. The directory is only special > to this nginx because it is named in the conf file. > > Good luck with it, > > f > -- > Francis Daly fran...@daoine.org > _______________________________________________ > nginx mailing list -- nginx@nginx.org > To unsubscribe send an email to nginx-le...@nginx.org >
_______________________________________________ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
