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

Valentin V. Bartenev vbart at nginx.com
Tue May 20 07:37:54 UTC 2014

On Tuesday 20 May 2014 09:01:45 B.R. wrote:
> 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.

Deleting a file doesn't make file descriptor "invalid".  It's valid and the 
file actually exists on file system till there is at least one descriptor 
pointing to that file.

  wbr, Valentin V. Bartenev

More information about the nginx mailing list