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>
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.
* 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
/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 }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 ```