Bug 2217134

Summary:	logwatch sends email twice
Product:	[Fedora] Fedora	Reporter:	Piergiorgio Sartor <piergiorgio.sartor>
Component:	logwatch	Assignee:	Frank Crawford <frank>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	43	CC:	anon.amish, frank, pmarciniak, sergio
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-05-28 13:14:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Piergiorgio Sartor 2023-06-24 07:27:04 UTC

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.

Comment 1 Frank Crawford 2023-06-24 10:29:02 UTC

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?

Comment 2 Piergiorgio Sartor 2023-06-24 13:25:32 UTC

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

Comment 3 Frank Crawford 2023-06-25 03:55:29 UTC

Thanks.  I'll continue to look into why it may have happened.

Comment 4 Aoife Moloney 2024-05-28 13:14:09 UTC

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.

Comment 5 Sergio Basto 2026-02-14 01:17:06 UTC

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)

Comment 6 Frank Crawford 2026-02-15 08:42:13 UTC

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.

Comment 7 Frank Crawford 2026-02-15 08:42:41 UTC

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.

Comment 8 Sergio Basto 2026-02-15 16:04:56 UTC

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.