Quick question about using kill -USR1 to recreate access.log
Alder Netw
aldernetwork at gmail.com
Wed Sep 27 20:17:35 UTC 2017
Hi Maxim,
We came across a case where kill -USR1 doesn't cause nginx reopen the
access.log. And we need to run nginx with "daemon off" and "master-process
off". Is that a known issue and is there any workaround?
On Tue, May 20, 2014 at 4:33 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Mon, May 19, 2014 at 03:06:06PM -0400, samingrassia wrote:
>
> > Thanks to everyone in advance!
> >
> > I have a cron that runs the following:
> >
> > 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?
>
> Unless you are trying to move logs to a different filesystem,
> logging will continue to the old file till USR1 is processed.
>
> From nginx point of view, the "mv" command does nothing - as nginx
> has open file descriptor, it will continue to write to it, and log
> lines will appear in the (old) file - the file which is now have a
> new name. After USR1 nginx will reopen the log, and will continue
> further logging to a new file.
>
> --
> Maxim Dounin
> http://nginx.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/20170927/bfd48a9f/attachment.html>
More information about the nginx
mailing list