Empty error and access log
francis at daoine.org
Fri Sep 27 07:07:51 UTC 2019
On Fri, Sep 27, 2019 at 01:36:55AM -0400, krishna wrote:
I do not have the answer for you. But...
> Figured out that, nginx.pid file doesn't have the correct PID value(it
> contains 1) - which could be valid since nginx is running inside docker
> container and we are setting up the log rotation from the host machine where
> the log files getting rotated but new files not getting logged further by
> nginx worker process.
> As per the comments tried to edit the nginx.pid file(with Nginx host PID),
> then issued command "kill -USR1 `cat /var/run/nginx.pid`" which works fine
> and new log files getting created and logged with data.
...what nginx needs is for its master process to receive a "USR1"
signal. It does not care how that is done.
As I understand it, docker includes a "kill" subcommand with a "-s" option
to send a specific signal to a container -- which should mean "to the
one process that is running in the container", which in your case should
> Had came across the blogs, they suggested to use nginx reload during post
> rotation as below with the logrotate,
> docker exec nginx bash -c "nginx -s reload 2>/dev/null"
> Kindly let me know, if above is a valid approach can be followed (or) to
> get the actual Nginx PID at host level & initiate kill command with USR1.
I think that there were good reasons explained not to send HUP when USR1
is all that is needed.
nginx writes its pid file to a well-known place. If "something else"
does virtualising or jailing or containerising or namespacing or any
other translation between nginx's idea of its pid and the rest of the
world's idea of the nginx pid, then it is that "something else's" job
to untranslate as well.
Which means: if you use docker to hide nginx from the system, you should
use docker to expose nginx to the system.
Ask docker for the "real" pid; or use docker to avoid having to find
Good luck with it,
Francis Daly francis at daoine.org
More information about the nginx