Bug 2217134 - logwatch sends email twice
Summary: logwatch sends email twice
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: logwatch
Version: 38
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Frank Crawford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-24 07:27 UTC by Piergiorgio Sartor
Modified: 2023-06-25 03:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.