Server Log Management: Size Control with logrotate

If you run a game server, server log management will eventually become a headache. Connections, chat records, GM commands, error messages and the thousands of lines your game engine produces pile up day after day. A single syserr.txt growing into gigabytes and filling the disk until the server crashes because it has nowhere left to write is a classic scenario. In this article I explain how to use Linux's standard tool, logrotate, to automatically rotate, compress and keep your log files under control.

Why do log files spiral out of control?

It does not matter whether you run Metin2, Minecraft, FiveM or your own C++ server; they all produce log files that are written to constantly. The problem comes from a single file growing forever:

• During peak hours hundreds of lines per second can be written; syslog, chat.log or syserr balloon quickly.
• Hunting for an error in one giant file becomes impossible; even grep takes minutes.
• When the disk fills up, not only logs but the database and game processes can no longer write; the server stops entirely.
• Backing up these huge log files every time wastes space and time for nothing.

The solution is to "rotate" the logs at regular intervals: archive the active file, start a fresh one, compress the old ones and delete anything beyond a set count. That is exactly what logrotate does.

How does logrotate work?

logrotate is installed on almost every Linux distribution. It is not a service (daemon) of its own; it is triggered once a day by cron or a systemd timer. On most systems the /etc/cron.daily/logrotate script does the job. When it runs it reads the configuration files, decides which logs need rotating and stores its state in /var/lib/logrotate/status, so it remembers "when did I last rotate this log?"

Configuration lives in two places:

• /etc/logrotate.conf — global settings.
• /etc/logrotate.d/ — a separate file per application. You drop your own rule for the game server here.

A sample configuration for a game server

Say your server logs are kept under /var/log/metin2/ with a .log extension. Create a file named /etc/logrotate.d/metin2:

/var/log/metin2/*.log {
    daily
    rotate 14
    size 100M
    missingok
    notifempty
    compress
    delaycompress
    copytruncate
}

What the directives mean:

• daily — rotate once a day. weekly or monthly also work.
• size 100M — rotate as soon as the file exceeds 100 MB, without waiting for the period. Critical on busy servers.
• rotate 14 — keep at most 14 old copies; the 15th is deleted.
• compress — compress old logs with gzip; this usually cuts space by around 90%.
• delaycompress — compress the most recently rotated file one cycle later; prevents data loss if a process is still writing to it.
• missingok — do not error if the file is missing.
• notifempty — do not rotate an empty file.
• copytruncate — copy the file and truncate the original, so the engine can keep logging without a restart.

copytruncate or create?

This is the most common mistake. By default logrotate works with create logic: it renames the active file and creates an empty file with the same name. But game servers keep the log file open and keep writing to the same file descriptor; even though the name changes, writes still go to the old file (now .1). The result: the new file stays empty and the old one keeps growing.

There are two solutions:

• copytruncate: logrotate takes a copy of the file, then truncates the original to zero size. The server, none the wiser, keeps writing to the same descriptor. A few lines written in the brief moment between copy and truncate may be lost, but no restart is needed. For most off-the-shelf game servers this is the most practical path.
• postrotate with a signal: if your server can reopen its log file on a signal, you notify it after the rotation. This removes copytruncate's risk of losing even a single line:

/var/log/metin2/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload metin2.service > /dev/null 2>&1 || true
    endscript
}

sharedscripts runs the postrotate block only once even when several files match the pattern.

Test first, trust later

Once you have written the configuration, do not just wait blindly. Try logrotate in dry-run mode; it shows what it would do without changing anything:

logrotate -d /etc/logrotate.d/metin2

The output shows which files would be rotated and operations like copytruncate. To actually force a rotation, use -f:

logrotate -f /etc/logrotate.d/metin2

Two common pitfalls: logrotate skips a configuration file for security reasons if it is writable by other users (world-writable) or not owned by root. Keep file permissions at chmod 0644 and ownership at root:root. You may also need the su user group directive to declare the owner of the log directory.

Frequently Asked Questions

Can I run logrotate more often, say hourly?

Yes. You can add hourly to the configuration, but because logrotate is triggered by a daily cron, running it hourly requires a separate cron entry or systemd timer. In most cases the size directive is more practical: the file is rotated on the daily run the moment it exceeds your chosen size.

Can I search inside compressed old logs?

Yes. The command zgrep "error" syserr.log.3.gz searches inside .gz files without unpacking them. zcat and zless work too.

Do I need to shrink my current huge log file first?

No; logrotate will rotate it on its first run. Still, if the disk is at a critical level you can force a rotation with -f to free space immediately. Never delete the file with rm while the process is running; the space will not come back, because the process still holds the file open.

Want your logs under control and your server free from crashes? We can sort out your game server's log infrastructure and general Linux maintenance together. Get in touch and let's set up a rotation plan that fits your server.