Hi all,
In the common case, people rotate access log like this:
mv access.log access.XXX.log
kill -USR1
In my case, I have to do something like this:
if [ -f “access.log” ]; then
mv access.log access.20130121.log
fi
kill -USR1
{wait until access.log was generated}
mv access.log access.20130122.log
My goal is make the “current” log file renamed with the date pattern
immediately, not after one day or other period. Well, my script seams
OK, but for a production script, I still worry about that is there any
“unexpected” trigger(other than send usr1 signal externally) can make
nginx reopen the log file? Will there be any inside reopen action in the
future?
2013/1/24 Liu H. [email protected]:
My goal is make the “current” log file renamed with the date pattern
immediately, not after one day or other period.
My first thought would be creating a symbolic (see “man ln”) from the
current log to the log-with-date-within-filename.
You would just have to change the symlink then … For example like
this: change target of a symbolic link Post: 302239409
So let access.log point to access.$(date “+%Y%m%d”).log (see
Unix time - Wikipedia ).
But I have no nginx running here at the moment.
Sorry I note that I didn’t describe it clearly. I am not looking for
another way of log rotating, but afraid of any other ‘trigger’ make
nginx reopen log file unexpectedly, which can break my logic. If its
sure that no any hidden trigger other than my script, then my design is
ok. I think there won’t be such kind of trigger, and I have to make it
sure.
Regards.
On Jan 24, 2013, at 7:42 AM, Liu H. wrote:
Sorry I note that I didn’t describe it clearly. I am not looking for another way
of log rotating, but afraid of any other ‘trigger’ make nginx reopen log file
unexpectedly, which can break my logic. If its sure that no any hidden trigger
other than my script, then my design is ok. I think there won’t be such kind of
trigger, and I have to make it sure.
I think the suggestion about the symlink was to make sure that if/when
nginx re-opens the file, it’s actually opening the file you want it
to–an alternative approach to what you’re doing, which does not care
when the file is re-opened.
–
Scott R.
[email protected]
http://www.elevated-dev.com/
(303) 722-0567 voice
2013/1/24 Scott R. [email protected]:
I think the suggestion about the symlink was to make sure that if/when nginx
re-opens the file, it’s actually opening the file you want it to–an alternative
approach to what you’re doing, which does not care when the file is re-opened.
Exactly. There’s only one file to be opened (this one, which the
symlink points to) and thus less danger of race conditions.
2013/1/24 Jan-Philip Gehrcke [email protected]:
Maybe I did not read carefully enough, but instead of relying on the $(date
“+%Y%m%d”) in the exact moment of renaming the file, you could use the last
modification time of the file via. e.g.
$ stat -c %y ~/.bashrc | awk ‘{print $1}’
2012-12-18
My version has no dashes 
And you could adjust the modification to not take place at midnight,
couldn’t you?
Regards, André
I did a test, seams cool, thank you all.
Maybe I did not read carefully enough, but instead of relying on the
$(date “+%Y%m%d”) in the exact moment of renaming the file, you could
use the last modification time of the file via. e.g.
$ stat -c %y ~/.bashrc | awk ‘{print $1}’
2012-12-18
On a busy web server this should almost always correspond to the day
when – in your words – the trigger was triggered 
HTH,
Jan-Philip