Log rotate

[dktapps]

Introduction

server.log is not rotated by default and grows unmanageably large, to the point where it's so huge that it's not possible to read it with any standard text editor anymore.

This PR implements automatic log rotation.

• When the server.log reaches 32MB in size, it's moved to the log_archive folder of the server's data folder.
• The archive's file name will look something like this: server.2024-03-15T15.26.24.0.log
• The file's name contains the date and time when the file was archived. This may be useful if you're trying to find logs from a particular time frame.

This has several benefits:

• Much more easily find logs from a particular time frame without scrolling through GBs of logs
• Free up space without stopping the server - Archived log files log_archive/ can be safely deleted and/or modified while the server is running

Why not automatically compress the files?

The original version of this PR did exactly that, but it created various problems, such as the possibility of the logger stalling while compressing large log files, disk running out of space, etc.

If you want to automatically compress or clean up the log files yourself, I suggest an external cron job or disk watcher.

Relevant issues

Closes #4029.

Changes

Behavioural changes

Described above.

Tests

This can be seen in action using the following script. It will generate 4 log files in $PWD/testlogsarchive.

<?php

require 'vendor/autoload.php';

$logWriter = new \pocketmine\utils\MainLoggerThread("test.log", getcwd() . "/testlogsarchive");
$logWriter->start();


for($i = 0; $i < 512 * 1024; $i++){
	$logWriter->write(str_repeat("a", 256));
}
echo "Waiting for logger thread to stop...\n";
$logWriter->shutdown();
echo "Done.\n";

[dktapps]

Blocked until pmmp/ext-pmmpthread#42 is resolved

[dktapps]

pmmp/ext-pmmpthread@b2b6100 should resolve the performance issue blocking this

[dktapps]

Another problem I hadn't foreseen: If a user with a very large log file (e.g. 50 GB) loads this code in their server, the MainLoggerThread will stall for several minutes as it compresses the old log file. This could cause loss of new logs, as the thread wouldn't be writing new log entries to the disk while this is happening.

We probably need an extra thread to solve this.

[dktapps]

I'm thinking this would be OK if we were to get rid of the compression step. If we have the server move old logs to a new location and release them, external systems can handle cleaning them up, compressing them, or whatever else. The only thing we really need to do is release handles to the file(s) containing the archival logs, so that they can be processed by other tools without stopping the server.