Version: logwatch-7.8-3.fc38.noarch Apparently, since FC 38, "logwatch" sends email using "/etc/cron.daily/0logwatch" and "logwatch.timer". For some reason, this was not happening with FC 37. Looking at the "logwatch.timer" status, it is reported "enabled", but preset "disabled". This was *not* manually changed from FC 37. Clearly, it would be easily possible to disable, question would be if this is correct or not and why it suddenly appears as enable there. In any case, if enabled (as it is), emails are duplicated, meaning that a mechanism is missing to prevent either the timer or the cron job to run again, once the other already did. Hope this helps. Thanks, pg Reproducible: Always Steps to Reproduce: 1. Install "logwatch" and a mail transport agent (sendmail) 2. Normal PC usage, either on / off or server like (always on) 3. Wait for logwatch(es) to run (daily, it seems) Actual Results: Duplicated mails are arriving. Expected Results: Only one mail a day should (should it?) arrive.
Huh? I'll have to look further, as logwatch.timer is not yet enabled by default for Fedora, we are still using the cron version only. Do you know if you did anything different during installation that would enable it?
Uhm, I do not recall to have done anything to get the timer enabled. Nevertheless, this happened on 3 PCs out of 4, so I guess it was something unforeseen. I'm not sure about the 4th, this seems to have the timer still disabled. The update was done all the same way, no fiddling with systemd... Maybe something about "resetting the services" went wrong (from my side or from the upgrade). Anyway, if you say the timer should be disabled, then I'll disable on all 3, no problem from my side. Thanks, bye, pg
Thanks. I'll continue to look into why it may have happened.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Yeah, I also see this in Fedora 43 [1]. systemctl status logwatch shows that it ran [2], and /etc/cron.daily/0logwatch also comes from the package, which makes logwatch run twice. [2] Feb 14 00:00:13 ideapad.local systemd[1]: Starting logwatch.service - Log analyzer and reporter... Feb 14 00:00:20 ideapad.local sendmail[111756]: 61E00IDK111756: from=root, size=62191, class=-60, nrcpts=1, msgid=<202602140000.61E00IDK111756>, relay=root@localhost Feb 14 00:00:20 ideapad.local sendmail[111756]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 Feb 14 00:00:20 ideapad.local sendmail[111756]: 61E00IDK111756: to=root, ctladdr=root (0/0), delay=00:00:02, xdelay=00:00:00, mailer=relay, pri=200191, relay=[127.0.0.1] [127.0.0> Feb 14 00:00:20 ideapad.local systemd[1]: logwatch.service: Deactivated successfully. [1] 1294 O + Feb 01 logwatch@ideapa (8899) Logwatch for ideapad.local (Linux) 1295 O + Feb 01 logwatch@ideapa (8899) Logwatch for ideapad.local (Linux) 1296 O + Feb 02 logwatch@ideapa ( 226) Logwatch for ideapad.local (Linux) 1297 O + Feb 02 logwatch@ideapa ( 226) Logwatch for ideapad.local (Linux) 1298 O + Feb 03 logwatch@ideapa ( 255) Logwatch for ideapad.local (Linux) 1299 O + Feb 03 logwatch@ideapa ( 261) Logwatch for ideapad.local (Linux) 1300 O + Feb 04 logwatch@ideapa ( 240) Logwatch for ideapad.local (Linux) 1301 O + Feb 04 logwatch@ideapa ( 240) Logwatch for ideapad.local (Linux) 1302 O + Feb 05 logwatch@ideapa ( 313) Logwatch for ideapad.local (Linux) 1303 O + Feb 05 logwatch@ideapa ( 313) Logwatch for ideapad.local (Linux) 1304 O + Feb 06 logwatch@ideapa ( 146) Logwatch for ideapad.local (Linux) 1305 O + Feb 06 logwatch@ideapa ( 146) Logwatch for ideapad.local (Linux) 1306 O + Feb 07 logwatch@ideapa ( 113) Logwatch for ideapad.local (Linux) 1307 O + Feb 07 logwatch@ideapa ( 113) Logwatch for ideapad.local (Linux) 1308 O + Feb 08 logwatch@ideapa ( 128) Logwatch for ideapad.local (Linux) 1309 O + Feb 08 logwatch@ideapa ( 128) Logwatch for ideapad.local (Linux) 1310 O + Feb 09 logwatch@ideapa ( 137) Logwatch for ideapad.local (Linux) 1311 O + Feb 09 logwatch@ideapa ( 137) Logwatch for ideapad.local (Linux) 1312 O + Feb 10 logwatch@ideapa ( 214) Logwatch for ideapad.local (Linux) 1313 O + Feb 10 logwatch@ideapa ( 214) Logwatch for ideapad.local (Linux) 1314 O + Feb 11 logwatch@ideapa ( 89) Logwatch for ideapad.local (Linux) 1315 O + Feb 11 logwatch@ideapa ( 89) Logwatch for ideapad.local (Linux) 1316 O + Feb 12 logwatch@ideapa ( 205) Logwatch for ideapad.local (Linux) 1317 O + Feb 12 logwatch@ideapa ( 205) Logwatch for ideapad.local (Linux) 1318 + Feb 13 logwatch@ideapa ( 183) Logwatch for ideapad.local (Linux) 1319 + Feb 13 logwatch@ideapa ( 183) Logwatch for ideapad.local (Linux)
I can’t find any where we are loading the systemd timer, and have not had any other reports on it. You really have two choices, either disable the timer, or disable the crontab file. In the near future I am looking at swapping to the timer version, but have not done so yet.
I found this [1] i.e preset is disabled but I had enabled it [1] systemctl status logwatch.timer ● logwatch.timer - Daily logwatch run Loaded: loaded (/usr/lib/systemd/system/logwatch.timer; enabled; preset: disabled) Active: active (waiting) since Fri 2026-02-13 14:16:22 WET; 2 days ago Invocation: c8e49c4a947c4fc7b9522006801dd0ff Trigger: Mon 2026-02-16 00:00:00 WET; 7h left Triggers: ● logwatch.service Docs: man:logwatch(8) man:logwatch.conf(5) Feb 13 14:16:22 ideapad.local systemd[1]: Started logwatch.timer - Daily logwatch run.