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