2

On 2025-07-15, my /var/log/nginx looked like this:

-rw-r--r-- 1 www-data www-data 1.9M Jul 15 13:02 access-2025-07-14.log -rw-r--r-- 1 www-data www-data 0 Jul 15 00:01 access.log -rw-r--r-- 1 www-data www-data 2.6K Jul 14 19:41 error.log -rw-r--r-- 1 www-data www-data 490K Jul 14 14:24 access-2025-07-11.log.gz -rw-r--r-- 1 www-data www-data 205K Jul 11 15:40 access-2025-07-09.log.gz -rw-r--r-- 1 www-data www-data 259K Jul 11 07:34 access-2025-07-10.log.gz -rw-r--r-- 1 www-data www-data 96K Jun 8 00:00 access-2025-07-05.log.gz -rw-r--r-- 1 www-data www-data 164K Jun 8 00:00 access-2025-07-06.log.gz -rw-r--r-- 1 www-data www-data 157K Jun 8 00:00 access-2025-07-07.log.gz -rw-r--r-- 1 www-data www-data 204K Jun 8 00:00 access-2025-07-08.log.gz 

Notice how access.log is empty and Nginx is writing to access-2025-07-14.log instead. If I call sudo logrotate /etc/logrotate.d/nginx, then Nginx switches to access.log, as expected from the postrotate script. But the daily run of logrotate managed by systemd apparently fails to do this. What's going on? I've looked at related questions like this one and this one and I can't find any permissions that seem awry.

Here's my /etc/logrotate.d/nginx:

/var/log/nginx/access.log { rotate -1 daily dateext dateformat -%Y-%m-%d extension .log dateyesterday missingok notifempty create 644 www-data www-data compress delaycompress sharedscripts postrotate if [ -f /tmp/hyarfernet_temp/nginx.pid ]; then kill -USR1 `cat /tmp/hyarfernet_temp/nginx.pid` fi endscript } 

Here are the permissions of parent directories:

drwxr-xr-x. 15 root root 4.0K Sep 10 2022 /var drwxrwxr-x. 14 root syslog 4.0K Jul 13 00:01 /var/log drwxr-xr-x 2 www-data www-data 4.0K Jul 15 00:01 /var/log/nginx 

I'm on Ubuntu Server 22.04 with Nginx 1.28.0 and logrotate 3.19.0.

3
  • 2
    Most likely logrotate is running with PrivateTmp in systems unit file, so it doesn't have access to /tmp/ and can't see /tmp/hyarfernet_temp/nginx.pid. Commented Jul 15 at 19:54
  • Does the nginx config specify the path of its logs? Commented Jul 16 at 13:12
  • @AlexD Thanks, great catch. I've changed it to PrivateTmp=false to see if that fixes it. @A.L. Yes: access_log /var/log/nginx/access.log. Commented Jul 16 at 18:04

1 Answer 1

2

@AlexD's comment was correct: the issue was PrivateTmp=true in /usr/lib/systemd/system/logrotate.service. With this changed to PrivateTmp=false, and Nginx manually signaled once in order to get it writing to access.log again, rotation now works properly.

3
  • 2
    The proper solution would have been to change your nginx config to write it's pid file to /var/run instead of /tmp. That's what the directory is for. Commented Jul 18 at 11:22
  • 1
    By disabling PrivateTmp you opened your server up for possible attacks. See systemd.io/TEMPORARY_DIRECTORIES Commented Jul 18 at 11:25
  • If there's malware or some unwanted guest on my machine, then I have much worse problems than scribbling on /tmp. Commented Jul 19 at 12:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.