On Tuesday 20 May 2014 09:01:45 B.R. wrote:
> On Mon, May 19, 2014 at 9:53 PM, Lord Nynex <lordnynex@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?
>
> There 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
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
