Logrotate Nginx: 7 Safe Steps for Ubuntu 24.04 & 26.04

A good logrotate nginx setup keeps your web server's log files from filling the disk: once a day, logrotate renames the current logs, tells nginx to open fresh ones, compresses the previous copy and deletes the oldest. This guide shows how to check what Ubuntu already does, extend it to per-site logs, test it without waiting a day, and avoid the one permission trap that makes rotation fail without any warning. It covers Ubuntu 24.04 LTS and 26.04 LTS, so pick yours with the switch below. Allow about 40 minutes; basic command-line skills are enough.

Every command here was run twice in disposable labs, once on Ubuntu 24.04 (nginx 1.24 and logrotate 3.21) and once on Ubuntu 26.04 (nginx 1.28 and logrotate 3.22), never on a live server. Where the two releases differ, the page shows only the one you picked. We use example.com, siteuser and documentation addresses as placeholders, so swap in your own names. Beside each command you get the plain-English reason for it, and why we chose it over the alternatives.

Before you start

You need a server running Ubuntu 24.04 LTS or 26.04 LTS, with nginx installed from Ubuntu's own repository and a user who can run sudo. If you are still building that server, start with our guides to hardening Ubuntu Server and to the WordPress web stack on nginx, PHP-FPM and MariaDB. Log rotation is low risk, but three habits keep it that way.

• Add your own file; leave the packaged one alone. Your rules go in a new file in /etc/logrotate.d/, so a package update has nothing of yours to overwrite or ask about.
• Keep a second terminal open running sudo tail -f /var/log/nginx/error.log while you test, so any nginx error appears the moment it happens.
• Check your paths. Ours match nginx from Ubuntu's repository. If you installed nginx another way (the nginx.org packages, a container or a source build), look in /etc/logrotate.d/ and /var/log/ first and adjust.

Why logrotate and not the other ways

There are several ways to stop logs growing forever. They are not equal, and the differences explain most of the choices later in this guide.

The rest of this guide is about doing the first row properly, because the defaults cover the common case and quietly miss the rest.

How logrotate nginx works, in plain English

Picture nginx as a clerk writing in a ledger. Every visit to your site adds a line. The clerk never looks at the ledger's label, only at the book in their hand. If someone renames that book "last week" and puts a fresh one on the desk, the clerk carries on writing in "last week". Linux programs behave the same way: they keep a log file open, and renaming it does not change where they write.

So rotation has four beats, in this order. First, logrotate renames the live log, so access.log becomes access.log.1. Second, it asks nginx to reopen its logs, which is what makes nginx start a fresh access.log. Third, it compresses older copies. Fourth, it deletes the copies beyond the number you chose to keep. The nginx documentation describes the same sequence: rename the files, send the master process the USR1 signal, and the old files are then free for work such as compression.

Skip the second beat and you get the classic failure. nginx keeps writing into the renamed file, the fresh access.log stays empty, and when logrotate later compresses and deletes the old copy, the disk space is not returned because nginx still holds the file open. Most "rotation does not work" stories are this one.

On both releases the schedule is a systemd timer, not cron: logrotate.timer starts logrotate.service once a day, which runs /usr/sbin/logrotate /etc/logrotate.conf. The old cron script steps aside when systemd is running. The main file sets the defaults (weekly rotation, keep four copies, run as root with group adm) and includes every file in /etc/logrotate.d/. Each package drops its own file there, and so will you. Our guide to systemd timers versus cron explains the difference.

Step 1: Look at what you have today

Before you change anything, find out whether rotation already works and where the space is going. These four commands take a minute.

df -h /
sudo du -xsh /var/log/* 2>/dev/null | sort -h | tail -8
ls -lh /var/log/nginx
systemctl list-timers logrotate.timer

The first command shows how full the disk is. The second lists the eight biggest items in /var/log, largest last. The third shows whether rotated copies exist, and the fourth shows when logrotate runs next. Healthy output for the third command looks like this (illustrative):

-rw-r----- 1 www-data adm  84K Oct  8 21:47 access.log
-rw-r----- 1 www-data adm 1.2M Oct  8 00:00 access.log.1
-rw-r----- 1 www-data adm  96K Oct  7 00:00 access.log.2.gz
-rw-r----- 1 www-data adm  11K Oct  8 21:45 error.log

Numbered copies mean rotation is working. The .1 file stays readable and older ones end in .gz, because the stock rule delays compression by one cycle. One huge access.log with no numbered siblings means nothing is rotating that file. Look in subfolders too, with ls -R /var/log/nginx, because the stock rule does not reach into them.

Step 2: Read the stock rule, line by line

Ubuntu's nginx package installs this rule in /etc/logrotate.d/nginx. Do not edit it. Just understand it, because your own rules will be small variations on it.

/var/log/nginx/*.log {
	daily
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 0640 www-data adm
	sharedscripts
	prerotate
		if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
			run-parts /etc/logrotate.d/httpd-prerotate; \
		fi \
	endscript
	postrotate
		invoke-rc.d nginx rotate >/dev/null 2>&1
	endscript
}

Step 3: Choose where each site's logs live

This decision matters more than any setting, and it comes before any configuration. When you host more than one site, each needs its own access and error log, and there are three common places to put them. If you are planning several sites on one machine, our guide to running multiple WordPress sites on one server covers the wider design.

One more reason to prefer a folder of your own: files that nginx creates itself start with permissions 0644, which means every account on the server can read them until the first rotation applies 0640. A folder set to 0750 keeps them private from the start.

The permission trap, in plain English

Layout C looks tidy and fails in an instructive way. When nginx is asked to reopen its logs, the main process (running as root) recreates the files. But the worker processes, which run as the unprivileged user www-data and do the actual writing, open the files again by name, as the nginx documentation notes. If the log folder belongs to another account and www-data is not allowed into it, the workers cannot open the new file.

Nothing crashes and the site stays up. nginx writes lines like this to its main error log at every rotation, one for each log file and each worker process (from our lab, with the path changed to the example domain):

2026/10/08 21:45:09 [emerg] 3310#3310: open() "/var/www/example.com/logs/access.log" failed (13: Permission denied)

What you notice, if you notice anything, is that the new access.log stays empty while access.log.1 keeps growing. In our lab test the workers carried on writing into the renamed file. Even after we deleted that file they kept its space allocated, which is the disk-full surprise covered in step 7.

Three ways out of the trap

Step 4: Add a logrotate nginx rule for per-site logs

This step is for layout B. If you chose layout A, skip to step 5, because the stock rule already covers you. First create the site's log folder, owned like the stock logs:

sudo install -d -o www-data -g adm -m 0750 /var/log/nginx/example.com

install -d creates the folder and sets its owner, group and permissions in one step. Then point the site at it in the server block. Only the two log lines are new; the rest of your server block stays as it is.

server {
    listen 80;
    server_name example.com;

    access_log /var/log/nginx/example.com/access.log;
    error_log  /var/log/nginx/example.com/error.log;
}

sudo nginx -t && sudo systemctl reload nginx

nginx -t checks the configuration for mistakes, and reload applies it without dropping visitors. Now create your rule. Run sudoedit /etc/logrotate.d/nginx-sites, paste the following, then save and exit:

/var/log/nginx/*/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

It is the stock rule with one change: the pattern */*.log means every .log file in every folder directly under /var/log/nginx. Everything else is deliberately identical, so your sites behave like the default logs. Two details are easy to miss. Never widen the pattern so that it also matches /var/log/nginx/*.log, because logrotate refuses to manage one file in two rules and reports duplicate log entry. And keep the name nginx-sites rather than nginx, so a package update never touches your file.

Common adjustments, all one line each:

• rotate 30 or rotate 90 keeps a month or a quarter of daily history instead of two weeks.
• weekly instead of daily suits quiet sites; maxsize 500M rotates early when a log passes 500 MB. logrotate only looks when it runs, which on Ubuntu is once a day, so a size limit cannot stop a log that balloons within a few hours.
• dateext names old copies by date (access.log-20261008) instead of by number.

Step 5: Test the rule before you trust it

Nobody wants to find out at midnight that a rule has a typo. logrotate has a dry-run mode that prints what it would do and changes nothing.

sudo logrotate -d /etc/logrotate.conf
sudo logrotate -d /etc/logrotate.conf 2>&1 | grep '^error:'

The -d option is debug mode: no changes are made to the logs and the state file is not updated. Scroll to your site's section and look for "considering log" lines. The second command shows only the lines that begin with error:, which is how logrotate reports a problem; no output means none were found. We test against the main file rather than only your new file because the main file supplies the defaults, and running a single rule file on its own skips them.

Now force one real rotation of just your rule, and look at the result:

sudo logrotate -f /etc/logrotate.d/nginx-sites
ls -l /var/log/nginx/example.com

The -f option forces a rotation even though a day has not passed. Check three things: a new, empty access.log exists with the owner and permissions from create; the earlier content is in access.log.1; and error.log shows nothing odd. A forced run counts as a real rotation, so on a site already holding 14 copies the oldest is deleted.

The most important check is the next one. Make a request to your own server and see where it lands:

curl -s -o /dev/null -H "Host: example.com" http://127.0.0.1/
sudo tail -n 2 /var/log/nginx/example.com/access.log
sudo tail -n 3 /var/log/nginx/error.log

The request should appear in the new access.log, not in access.log.1, and the main error log should show no [emerg] lines. If the new file stays empty, go to the troubleshooting table below.

Finally, run the real service once, because that is what the timer does, and it runs inside a more restricted environment than your shell:

sudo systemctl start logrotate.service
journalctl -u logrotate.service -n 5 --no-pager

A clean run ends with "Finished logrotate.service". It only rotates what is actually due, so it is a check of the plumbing rather than of the schedule. We also ran this in both labs with a size-triggered rule and confirmed that the stock postrotate command works inside the service's sandbox.

Step 6: Cover the other logs that fill disks

nginx is rarely the only thing writing logs. Three others cause most of the surprises, and one habit reduces the volume before it reaches the disk.

PHP-FPM's own log

PHP-FPM keeps its log file open just as nginx does, so it needs the same reopen trick. On Ubuntu the package already ships the rule and a helper that makes PHP-FPM reopen its log, so there is usually nothing to do. The names carry the PHP version, which is 8.38.5 on this release. Confirm the rule exists with ls /etc/logrotate.d/php8.38.5-fpm. This is what it contains:

/var/log/php8.38.5-fpm.log {
	rotate 12
	weekly
	missingok
	notifempty
	compress
	delaycompress
	postrotate
		if [ -x /usr/lib/php/php8.38.5-fpm-reopenlogs ]; then
			/usr/lib/php/php8.38.5-fpm-reopenlogs;
		fi
	endscript
}

If you run extra PHP-FPM pools with their own log files, copy this rule, change the path, and keep the helper call.

Application logs such as the WordPress debug log

When WordPress debugging is switched on, it writes wp-content/debug.log, and nothing ever empties it. This file needs less ceremony than nginx's, because PHP opens its log file for each message, writes the line and closes it again. We confirmed that in the lab: after we renamed the file mid-run, the next message created a fresh one. A plain rename is enough, with no signal and no copytruncate:

/var/www/example.com/public/wp-content/debug.log {
    su siteuser siteuser
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

The su line makes logrotate do the work as the site's own account. It is also required if the folder can be written by a group other than root: logrotate then refuses, by design, with skipping ... because parent directory has insecure permissions, since root working inside a folder another account can change is a classic way to be tricked into touching the wrong file. The same applies to any log inside a site's own folder.

Debugging should be off in production unless you are chasing a problem, but rotate the file anyway, because somebody will forget to turn it off.

The systemd journal

Ubuntu also keeps a system journal, which logrotate does not manage. Check its size with journalctl --disk-usage. By default, the manual says, it may use up to 10% of the file system, with each limit capped at 4 GB. To set your own limits, add a drop-in file rather than editing the main one. Run sudoedit /etc/systemd/journald.conf.d/50-size-limit.conf and add:

[Journal]
SystemMaxUse=500M
MaxRetentionSec=1month

sudo systemctl restart systemd-journald
journalctl --disk-usage

In our labs the journal's start-up message then reported max 500.0M500M, which confirms the limit took effect. These limits apply when the journal is stored on disk, which is the case when /var/log/journal exists. A drop-in is safer than editing /etc/systemd/journald.conf because package updates never overwrite your file, and the files are read in alphabetical order, so a number at the start of the name controls precedence.

Write less log in the first place

Some requests are noise: a monitoring service pinging a health-check URL every ten seconds adds thousands of useless lines a day. nginx can skip logging for just that path:

location = /healthz {
    access_log off;
    return 200 "ok\n";
}

The off value cancels access logging at that level only. Do not switch off the access log for a whole site, because it is the record you will want when something goes wrong or someone asks where a visitor came from.

Step 7: Watch the disk and know the emergency moves

Rotation is not entirely set and forget. Once a month, spend two minutes on these checks, ideally when you apply updates:

df -h /
sudo du -xsh /var/log/* 2>/dev/null | sort -h | tail -5
sudo lsof +L1 | grep -E 'COMMAND|nginx'
journalctl --disk-usage

The third command is the one few people know. lsof +L1 lists files that were deleted but are still held open by a program (if the command is not found, sudo apt install lsof adds it). If nginx appears with a large size, that space is being held by a file you cannot see in any folder. Example output (illustrative):

COMMAND  PID     USER   FD TYPE DEVICE SIZE/OFF NLINK     NODE NAME
nginx   3388 www-data  31w  REG  0,133 20971603     0 28996664 /var/www/example.com/logs/access.log (deleted)

Set an alert at about 80% disk use in whatever monitoring you already have, such as your hosting provider's dashboard, an uptime service or a monitoring agent. A slowly filling disk is one of the few server failures you can see coming for days.

If the disk is full right now

Find the biggest file with the du command above, then truncate it instead of deleting it:

sudo truncate -s 0 /var/log/nginx/example.com/access.log

This is the one place where the obvious move is wrong. In our lab, deleting a 20 MB log that nginx had open freed nothing: the main process and every worker still held the deleted file, shown by NLINK 0 and the "(deleted)" tag. Truncating to zero frees the space at once, and nginx carries on appending at the start of the same file.

If you have already deleted a log, ask nginx to let go with sudo nginx -s reopen. If the space does not come back, you are in the permission trap from step 3, because the workers could not reopen the file. In our lab, sudo systemctl reload nginx finished the job within seconds and without dropping visitors, because the old workers exit once they finish their current requests. A full restart works too but interrupts connections, so we avoid it.

Troubleshooting: what the symptoms mean

Common mistakes

• Editing the packaged /etc/logrotate.d/nginx instead of adding a file of your own.
• Rotating without telling nginx: a rule that renames the file but has no reopen step.
• Using copytruncate everywhere out of habit, accepting a small risk of lost lines when a clean reopen was available.
• Testing only with -d and never forcing one real rotation and checking where the next request lands.
• Deleting a log with rm to free space, then wondering why the disk is still full.
• Leaving WordPress debug logging on for months with no rule to rotate its file.

Keep it healthy

Treat log rotation as part of routine maintenance rather than a one-time job. Each month, run the checks from step 7. Whenever you add a site, give it a log location that fits your layout and run sudo logrotate -d /etc/logrotate.conf to confirm no errors. After a major Ubuntu or nginx upgrade, repeat the forced rotation test once. Our WordPress maintenance checklist and Linux server hardening checklist list the other jobs that belong in the same routine.

Getting help

If you would rather not own this job, MEI's infrastructure and private cloud service covers Linux administration, monitoring and updates, and starts at $2,500, scoped by systems and scale. Managed Website and IT Care starts at $149 a month, with scope-based tiers that include updates, backups and monitoring. Both begin with a look at what you actually run.