Problem running nginx in a container

[Francis Daly]

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