logrotate (?) screws it badly

L
  • 6 Oct '23
Hi guys.

I run off distro's vanilla-default logrotate, like so:

/var/log/nginx/*log {     daily     rotate 10     missingok     notifempty     compress     delaycompress     sharedscripts     postrotate         /bin/kill -USR1 cat /run/nginx.pid 2>/dev/null 2>/dev/null || true     endscript }


and I wonder...
if it is logrotate's _fault_ or perhaps I screwed Nginx's 
configs somewhere? For after logs got rotated Nginx logs into:
access.log.1 & error.log.1
and now as it should, you know
access.log & error.log

many thanks, L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20231006/c3cc737f/attachment.htm>
R
  • 6 Oct '23
>    postrotate
>       /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
 >  endscript
>}

and I wonder... if it is logrotate's fault or perhaps I screwed Nginx's configs somewhere? For after logs got rotated Nginx logs into: access.log.1 & error.log.1 and now as it should, you know access.log & error.log

You need to check if the postrotate command completes successfully (for example - is the pid file in correct path? / I would remove all the || true parts and just leave kill -USR1 cat /run/nginx.pid).

Now it seems that logrotate just renames the files but nginx is not getting the signal and still has open handle to them so keeps logging in the renamed file.

rr ```

R
  • 6 Oct '23
* lejeczek via nginx:

> For after logs got rotated Nginx logs into:
> access.log.1 & error.log.1
> and now as it should, you know
> access.log & error.log

You may want to try logrotate's "copytruncate" option.

-Ralph