Quick question about using kill -USR1 to recreate access.log
Lord Nynex
lordnynex at gmail.com
Mon May 19 19:53:55 UTC 2014
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? Why not use nginx reload? Why not use HUP?
On Mon, May 19, 2014 at 12:36 PM, Francis Daly <francis at daoine.org> wrote:
> On Mon, May 19, 2014 at 03:06:06PM -0400, samingrassia wrote:
>
> Hi there,
>
> > mv $NGINX_ACCESS_LOG $ACCESS_LOG_DROPBOX/$LOG_FILENAME
> > kill -USR1 `cat $NGINX_PID`
> >
> > My questions is during time between the mv and the kill, is there any log
> > writes that are being discarded or are they being stacked in memory and
> > dumped into the new access.log after it is recreated?
>
> What happens when you do
>
> mv $NGINX_ACCESS_LOG $ACCESS_LOG_DROPBOX/$LOG_FILENAME
>
> and then issue a http request of your nginx server, before the kill?
>
> Do you see the log line go into $NGINX_ACCESS_LOG; onto the end of
> $ACCESS_LOG_DROPBOX/$LOG_FILENAME; or disappear without being written
> anywhere?
>
> I'd expect the first option not to happen; the second option to happen
> if the "mv" is a "rename"; and the third option to happen if the "mv"
> is a "copy and delete". So make sure that your "mv" is a "rename",
> and you'll be fine.
>
> Actually, I'd expect the first option to happen if you are using variables
> in your log file name, according to its documentation.
>
> f
> --
> Francis Daly francis at daoine.org
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140519/dbd736c3/attachment.html>
More information about the nginx
mailing list