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

[B.R.]

On Tue, May 20, 2014 at 9:37 AM, Valentin V. Bartenev <vbart at nginx.com>wrote:

> 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.
>

​Thanks for that Valentin, I learned something today.

I read
http://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handler-on-linux-if-the-pointed-file-gets-moved-de#2031100
As I understand it, all log messages going to a moved file​

​will still be printed into it.
So if I move /var/log/nginx/access.log to /foo/bar.log, all error log
message will continue to be printed in /foo/bar.log, until I send the USR1
signal to nginx (either master or workers), which will then close the file
descriptor (thus effectively delete /var/log/nginx/access.log which was
marked for deletion until then)​ and will create a new file in
/var/log/nginx/access.log
Am I right?
I suspect the file does not really move out of /var/log/nginx if at least
one fd is open on it. I suspect then that there is a symlink created in
/foo/bar.log pointing to the old file until it is effectively moved.

Does the same happens if the file is moved on a remote disk (ie does the
fact that a file is moved through copy+delete rather than rename have any
impact?)
​
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140520/20a24601/attachment.html>