MongoDB 8.x.x is one of those services that can run quietly for a long time, until one day you check disk usage and realize the log file has grown into something unreasonable. Not because MongoDB 8.x.x is broken, but because the logging behavior is doing exactly what it was told to do, keep writing, keep appending, and never stop unless someone outside the process manages rotation properly.

This is a common situation on Debian-based servers, Debian 12/13, especially when MongoDB 8.x.x is configured to write logs into a dedicated storage path and logAppend: true is enabled. At first glance, everything looks normal.

The server runs. Replication works. Authentication is enabled. Nothing crashes. But the log file quietly grows and grows until it starts eating storage much faster than expected.

In this article, we will look at why this happens, what MongoDB actually means by log rotation, and the clean Debian-friendly way to keep the log file under control.

The Configuration That Looks Fine, Until It Isn’t

A typical MongoDB 8.x.x configuration on Debian might look like this:

systemLog:
  destination: file
  logAppend: true
  path: /mnt/disk-log/mongodb/mongod.log
  logRotate: reopen
Code language: JavaScript (javascript)

At a glance, this seems like log rotation is already configured. That assumption is where many administrators get trapped.

The key thing to understand is that logRotate: reopen does not mean MongoDB 8.x.x will rotate the log automatically by itself. It only defines how MongoDB 8.x.x behaves when a log rotation event is triggered externally. In other words, MongoDB 8.x.x is prepared to reopen the log file, but something else still needs to perform the actual rotation.

With logAppend: true, MongoDB 8.x.x keeps appending to the same file across restarts. That is usually desirable, because you do not want logs truncated every time the service restarts. But without a proper rotation mechanism, the file will simply continue growing forever.

Why the Log File Keeps Growing

There are two separate concerns here, the first is where MongoDB 8.x.x writes logs, the second is who rotates them.

MongoDB 8.x.x can write to a file, and it can react when rotation happens. But on Linux, especially on Debian 12/13, the actual rotation is typically handled by the operating system through logrotate.

This means your current configuration is only half of the solution.

MongoDB 8.x.x is ready to reopen the log file after rotation. But if you do not configure Debian’s 12/13 logrotate to rename the file and notify MongoDB 8.x.x, then nothing ever rotates.

The result is predictable, one endlessly growing mongod.log.

The Right Way on Debian 12/13

The clean and standard solution is to let Debian’s logrotate manage the file, while MongoDB stays configured with logRotate: reopen.

That pairing is important, MongoDB 8.x.x should continue using

systemLog:
  destination: file
  path: /mnt/disk-log/mongodb/mongod.log
  logAppend: true
  logRotate: reopen
Code language: JavaScript (javascript)

Then create a logrotate policy such as

/mnt/disk-log/mongodb/mongod.log {
    daily
    rotate 14
    maxsize 100M
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    create 640 mongodb mongodb
    postrotate
        /bin/kill -SIGUSR1 $(pidof mongod) 2>/dev/null || true
    endscript
}
Code language: JavaScript (javascript)

This does several useful things at once.

It rotates the log daily.
It also rotates when the file exceeds 100 MB.
It keeps 14 archived logs.
It compresses older logs to save disk space.
And after rotating the file, it tells MongoDB to reopen its log handle using SIGUSR1.

That last step is the critical piece. Without it, MongoDB 8.x.x may continue writing to the old file descriptor even after rotation.

Why reopen Matters

MongoDB 8.x.x supports different log rotation behaviors, but on Linux the practical pattern is simple: let the OS rename the log file, then signal MongoDB 8.x.x to reopen it.

That is exactly what logRotate: reopen is for.

This mode works well with logrotate because the external tool handles the rename, while MongoDB 8.x.x responds by reopening the file path and continuing cleanly into a fresh log file.

This is also why using copytruncate is generally not the preferred choice here. copytruncate copies the log contents to a rotated file and then truncates the original file in place. It can work for some applications, but for MongoDB 8.x.x the cleaner method is rename plus signal.

In short, if you already use logRotate: reopen, stay consistent and let logrotate do the rename properly.

Reducing Log Noise

Rotation solves the storage growth problem, but sometimes the logs are not just large. They are also noisy.

If the file is growing unusually fast, you may also want to reduce how much MongoDB writes in the first place.

One conservative option is to add

systemLog:
  destination: file
  path: /mnt/disk-log/mongodb/mongod.log
  logAppend: true
  logRotate: reopen
  quiet: true
Code language: JavaScript (javascript)

The quiet setting reduces certain routine log messages. It will not eliminate important warnings or errors, but it can help cut down unnecessary chatter on busy systems.

At the same time, make sure you are not running with increased debug verbosity. Unless you are actively troubleshooting, there is no reason to raise MongoDB 8.x.x log verbosity above the default.

Higher verbosity levels can cause logs to balloon much faster than expected.

When Big Logs Are Actually a Symptom

Sometimes a giant MongoDB log is not just a rotation problem. It is also a sign that the server is trying to tell you something repeatedly.

Common causes of excessive MongoDB log growth include

• Repeated authentication failures
• Noisy connection attempts from applications or monitoring tools
• Replication instability or frequent state changes
• Aggressive health checks
• Temporary debugging settings left enabled
• Problematic clients connecting and disconnecting in high volume

So while log rotation is the immediate fix, it is also worth glancing through the log itself before archiving everything away. If the same message appears thousands of times, the real problem may be somewhere else.

A small log that rotates normally is healthy, a huge log that rotates normally may still be warning you.

How to Apply and Test It

On Debian, once you save the logrotate file, test it before waiting for the daily scheduler:

sudo logrotate -d /etc/logrotate.d/mongod

That performs a dry run.

If the output looks correct, force a rotation test:

sudo logrotate -f /etc/logrotate.d/mongod

Then verify the result

ls -lh /mnt/disk-log/mongodb/

You should see the active mongod.log plus rotated files, and older ones may appear compressed depending on your settings.

This simple validation step is worth doing immediately. It confirms that the file path is correct, ownership is correct, and MongoDB 8.x.x is reopening the log as expected.

A Practical Recommendation

If you are running MongoDB 8.x.x on Debian 12/13 and storing logs in a custom path, the safest practical setup is this

Use logAppend: true
Use logRotate: reopen
Manage rotation with Debian logrotate
Signal MongoDB with SIGUSR1 after rotation
Optionally enable quiet: true if routine log noise is excessive

That gives you predictable log growth, retained history, compressed archives, and no surprise disk explosion months later.

This is not a flashy optimization. It is not the kind of change that makes dashboards look better or benchmark scores improve. But it is exactly the kind of quiet operational hygiene that keeps a production server sane.

And often, that is what matters most.