Access logs hang

[B.R.]

>From what you explain, that problem most probably come from the way you
actually do the log rotation.
I first suggest you read how nginx handle it on the nginx control docs
<http://nginx.org/en/docs/control.html#logs>.

It seems nginx is not able to find your old log file when you moved the old
one.
You will notice that nginx keeps the old file open until a new one is
opened, and you will notice that the old file must be *renamed* (thus, from
what I understood, moving the file within the same filesystem is OK, since
the inode remains the same, due to the file descriptor being open).

If you are unsure about the the internals of *mv*, either use *rename* or
ensure you do not move the file out of the log directory previous to having
switched to the new one.
If you are running on another OS than GNU Linux, you will need to know what
the file utilities you use actually do and seek for a way to rename the old
log file without destroying the ability for nginx to keep the old file
open, even with a new name.

Even if that part seems OK, ensure the 'reopen' command equals a USR1
signal and is sent to the master process.
Once the signal is issued, you can then move the old log file wherever you
wish.
---
*B. R.*

On Thu, Oct 9, 2014 at 2:32 AM, Lorenzo Raffio <multiformeingegno at gmail.com>
wrote:

>  From time to time access logs (for which I don't have a logrotation and
> manually rotate them) just "hang" and no lines are written. Same file and
> folder. No change in Nginx config! And the fact seems totally random, it's
> not related to file size, it happens to files some kilobytes long, and
> other with nearly 100 Mb of lines. As soon as I run "nginx -s reopen", they
> start working again. Any idea?
>
>
> _______________________________________________
> 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/20141009/d5422f6d/attachment-0001.html>