Quick question about using kill -USR1 to recreate access.log

[B.R.]

On Mon, May 19, 2014 at 9:53 PM, Lord Nynex <lordnynex at gmail.com> wrote:

>
> The name of the file is really sort of irrelevant. The file descriptor
> will still point at $ACCESS_LOG_DROPBOX/$LOG_FILENAME. Any log lines
> between MV and KILL *should* still be written there.
>
> Why not use logrotate?
>

​Th​ere has been no precision on *why* the user wanted to mv the log file
somewhere else. Stating that is for log rotation/storage purpose is
speculation.

Why not use nginx reload? Why not use HUP?
>

​You​

​are repeating yourself, as the first usually equals the second (the
service 'reload' command is usually a wrap-up of the -HUP signal)​

As Francis suggested, there should be special care about what the moving
command will do:
The docs abut controlling nginx
<http://nginx.org/en/docs/control.html#logs>say that the old log file
will remain opened until the -USR1 signal closes
file descriptors pointing to it.
- A local 'mv' will keep the same inode, thus only renaming the file and
keeping opened file descriptors on it intact. You want that since all
incoming log messages will continue to be sent to this file until the -USR1
signal switches to a new one.
- On the contrary, a remote 'mv' (ie moving file to network storage) will
copy and *delete* the file, making the file descriptor opened by nginx
invalid.

The docs do not say what happens to log messages trying to be sent to
invalid fd, although as Francis suggest, it might be simply discarded.
Maybe are there some buffers FIFO-like n front of the fd that would retain
some of the messages? Pure speculation.
I have not had a look to the sources, if someone is around to provide us
with that information (or better: put a wuick word on it in the docs), I
would be glad. :o)
​
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140520/f33b7ab8/attachment-0001.html>