[mrrobot47]

Stops log rotation from failing for good once a log is bigger than the free disk space. Stacked on #1958, so merge that one first. Until then this PR's diff also shows #1958's commits, and the change here is the last commit only.

Problem

All three rules EasyEngine installs (ee_nginx_proxy, ee_sites, ee_cli) use copytruncate. logrotate copies the whole live log to .1 and only then truncates it, so a rotation needs as much free space as the log itself. On a busy server the nginx-proxy access.log reached about 20 GB. One night the copy didn't fit, logrotate logged error copying … No space left on device and left the log in place, and the same thing happened every night after that while the log kept growing. Each failed copy also filled the disk for several minutes around midnight, so backups and databases running at that moment failed. Nothing recovers from that state without a manual truncate.

#1958 adds maxsize and an hourly run, which keeps logs small in normal operation. It doesn't fix this failure: if free space ever drops below the log size, copytruncate fails, and the log grows past maxsize from then on.

What changes

The three rules rename the log and have the writer reopen it, which needs no extra space:

• ee_nginx_proxy runs nginx -s reopen in the container whose compose service is global-nginx-proxy, found with docker ps -f label=com.docker.compose.service=global-nginx-proxy instead of a hard-coded container name. It can't use docker kill -s USR1, because PID 1 in the nginx-proxy image is forego, not nginx.
• ee_sites sends USR1 to each site's nginx and php containers (io.easyengine.site label plus the compose service name). In both images the master process is PID 1 (openresty, and php-fpm through an exec entrypoint), and both reopen their logs on USR1.
• ee_cli just drops copytruncate. Each ee run opens ee.log again, so nothing needs a signal.

delaycompress stays, so the renamed file isn't compressed until the next rotation, after the writer has moved to the new file. The postrotate scripts end in || true: a stopped proxy or site has nothing writing to its log, so a failed signal there is harmless.

Existing installs pick up the new rules on the next ee cli update, because the setup step rewrites any EasyEngine rule whose content differs. No migration is needed.

Not in this PR

• Lower retention or dateext. rotate 30 with compressed archives isn't what fills disks. fix(logrotate): cap host syslog and mail.log growth #1958 already sets dateformat for hosts that enable dateext.
• Reporting a failed rotation. logrotate still exits non-zero and logs to the journal, as before.

Testing

Throwaway containers only: a docker:dind container acted as the EasyEngine host, so the postrotate label filters only ever matched the test containers. Images are the ones img-versions.json pins: easyengine/nginx-proxy:v4.13.0, easyengine/nginx:v4.11.0 and easyengine/php8.3:v4.13.3. The rules were rendered from Utils.php before (#1958 head) and after this change, and run with the logrotate from the docker:dind image (Alpine).

• php -l is clean on PHP 7.4 and 8.5, and logrotate -d accepts all three new rules (Ubuntu 24.04).
• Proxy logs on a 64 MB tmpfs holding a 40 MB access.log (24 MB free):
  • Old rule: error copying …/access.log to …/access.log.1: No space left on device, exit 1, log left in place.
  • New rule: exit 0, access.log renamed to access.log.1. nginx's open files point at the new access.log, and a request made after the rotation is logged there and not in .1.
• maxsize with a non-forced run (what the hourly job from fix(logrotate): cap host syslog and mail.log growth #1958 does): right after the forced rotation, the run reports log does not need rotating (log has already been rotated). Once access.log is 1.1 GB, the next run reports log needs rotating and renames it, and new requests go to the new file.
• Site rule: a forced rotation renames the site's nginx and php-fpm logs, and after the USR1 both containers' PID 1 hold the new files open.

Proxy rule, old and new:

Site rule: