Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a problem with nginx/logrotate. The problems is that nginx is logging access to 2 files (main and data).

I have the following contrab setting: 0 * * * * /usr/sbin/logrotate -f /home/orwell/orwell-setup/bin/logrotate-nginx

And the file "logrotate-nginx" has the following content:

/tmp/data.log {
    rotate 90
    daily
    missingok
    notifempty
    size 1
    sharedscripts
    postrotate
        [ ! -f /tmp/nginx.pid ] || kill -USR1 `cat /tmp/nginx.pid`
        MORE THINGS
    endscript
}


/tmp/main.log {
    rotate 90
    daily
    missingok
    notifempty
    size 1
    sharedscripts
    postrotate
        [ ! -f /tmp/nginx.pid ] || kill -USR1 `cat /tmp/nginx.pid`
        MORE THINGS
    endscript
}

The work is done in the two files, but there is a problem that nginx stops logging into those files. Both files are created, but they are empty.

Any ideas why nginx stop logging info to both files?

share|improve this question
    
Do log files permissions allow nginx to write into them? –  Alexander Azarov Mar 16 '10 at 17:59
    
Do nginx actually use /tmp/nginx.pid PID file? –  SaveTheRbtz Mar 17 '10 at 22:25
    
on a side note.. you'd be better grouping the 2 log files so you aren't huping the server twice /tmp/data.log /tmp/main.log { –  Mike Jun 27 '11 at 4:40
add comment

2 Answers

A bit late, but I've found it seems like its a bug in the USR1 signalling to nginx. According to the documentation it is meant to re-open the logs (http://wiki.nginx.org/LogRotation), but it doesn't appear to.

I've put a workaround in by sending a HUP instead, which will reload the configuration.

[ ! -f /tmp/nginx.pid ] || kill -HUP `cat /tmp/nginx.pid`

It appears to fix it, but if the USR1 call was working, it would be healthier to do that as its the minimal operation. HUP I don't think will drop any connections at least.

share|improve this answer
    
Mark this as correct answer, so that the community bot does not randomly poke the thread in order to get it answered, please. –  3molo Jun 27 '11 at 4:46
add comment

A bit late, but I've found it seems like its a bug in the USR1 signalling to nginx.

You must check rights for log folder. Nginx user must have execute/search privilege on that folder.

And logs are working after signal USR1:)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.