diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-04 12:15:00 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-04 12:55:01 +0200 |
| commit | 28653ea5ac7472233425ad8f77837dba5bf4e286 (patch) | |
| tree | 672cb216fcb0dd7228f2297bcd420fb0794ba813 /.gitignore | |
| parent | 74d1da2755ff8e1a47bda676fab7b84e910ef738 (diff) | |
| download | qtmaildir-28653ea5ac7472233425ad8f77837dba5bf4e286.tar.gz qtmaildir-28653ea5ac7472233425ad8f77837dba5bf4e286.zip | |
fix(sync): stop mailsync.sh rotating a log logrotate already owns
Two problems, both visible in the first real run of the moved script.
Every line was logged twice. The script writes to the log through tee,
and the user's crontab also ended in ">> mailsync.log 2>&1", so both put
the same output there. Reproduced: without the caller's redirect one run
writes a single RUN START, with it, two. The crontab redirect goes away
and the script keeps owning the log, which is what makes it behave the
same however it is invoked. A comment in the header now says so, since
the obvious cron line is the one that breaks it.
The internal size-based rotation is removed outright.
/etc/logrotate.d/mailsync already owns this file and keeps seven
compressed days, and the two were fighting: the script's
"mv $LOGFILE $LOGFILE.1" overwrites whatever logrotate had just placed
at .1, which is why that file was 357K and uncompressed while .2 through
.5 were properly gzipped. logrotate is better at this in every respect,
including recreating the file with the right ownership, so the script
should not have a second opinion.
Verified against stub mbsync and notmuch in a fake HOME: one RUN START
per run, stdout and the log agree, no rotation performed by the script,
and a failing mbsync or notmuch still produces its own exit code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to '.gitignore')
0 files changed, 0 insertions, 0 deletions
