Problem running nginx in a container

[OTH]

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 <francis at 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        francis at daoine.org
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20220206/b52b7fad/attachment.htm>