Description of problem: I'm getting a ton of useless stuff in logwatch every morning in the "kernel audit" section. I know how to disable audit reporting entirely, but there are times when audit messages are useful. Is this just a case of the logwatch scripts not up to date with the messages in F22? Sample logwatch output: https://gist.github.com/sterndata/8b0f7474bfa2536a7870:
AFAIK systemd writes the audit messages to the journal (or /var/log/messages if you don't use the journal), and they seem to be slightly differently formatted. I believe that logwatch already parses the audit messages from /var/log/audit/. I think that #1227379 has to be solved first.
Adding Service = "-audit" to /etc/logwatch/conf/logwatch.conf has removed the stuff from logwatch, but that's just the equivalent of putting a piece of black tape over the warning light.
*** Bug 1232565 has been marked as a duplicate of this bug. ***
*** Bug 1237222 has been marked as a duplicate of this bug. ***
This seems to be something new in F22; I just upgraded a system yesterday from an older F22 to current and it started doing this. Unfortunately while I could try to extract the new packages, I'm not sure whether I can find the older packages I upgraded from.
I only get lines like this one in **Unmatched Entries**: audit: <audit-1131> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" e xe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' On a very quiet server (just two services running) I get 300-400 hundred of these every day. logwatch-7.4.1-5.20150731svn293.fc22.noarch The patch from bug 1232565 seems to work fine.
The patch from bug 1232565 only reduced the number of lines by approx 50% in my case. So I removed the patch.
I've noticed this also. Jan do you know if this has reported upstream? It's not critical but definitely causes one to tend to completely ignore the entire section due to all the false positives.
I don't know but I guess it's not, as this is caused by systemd logging into the common log. It's not really a problem in logwatch and as I mentioned in comment #1, the systemd report should be resolved first. As a workaround, you can always put custom ignore expressions to /etc/logwatch/conf/ignore.conf.
Great thanks.
Just in case it helps anybody else, I fixed this on my server by doing the following, which removes the successful results and leaves everything else (and thus cuts down most of the clutter): ====================== cp /usr/share/logwatch/default.conf/services/audit.conf /etc/logwatch/conf/services echo '*Remove = "<audit-[0-9]+> pid=[0-9]+ uid=[0-9]+ auid=[0-9]+ ses=[0-9]+ subj=.*res=success"' >> /etc/logwatch/conf/services/audit.conf ====================== And then you can test it with: logwatch --service audit --range today Seemed a little bit easier to me than trying to change the files that get installed by the package directly, and so far it's working very well for my needs.
Or for Fedora 23 (for the same supression as my last post in Comment 11): ====================== cp /usr/share/logwatch/default.conf/services/audit.conf /etc/logwatch/conf/services echo '*Remove = "audit: \S+ pid=[0-9]+ uid=[0-9]+ auid=[0-9]+ ses=[0-9]+ subj=.*res=success"' >> /etc/logwatch/conf/services/audit.conf ====================== I like this better than adding it to the ignore.conf file because it seems to affect what is actually matched, rather than just suppressing the output (in which case you'll only be ignoring the printed lines if there are more than 100, so you might miss actual important messages).
If I apply this workaround, it gets rid of some of the noise I see in logwatch. The remaining lines all look like this: audit: PROCTITLE proctitle=73656E646D61696C3A207365727665722036342E3235332E33302E3231302E64796E2D652D706F6F6C33392E706F6F6C2E686172677261792E6E6574205B36342E3235332E33302E3231305D2073746172747570 This is on a system upgraded from Fedora 21 to 23, in case that makes a difference. I haven't done anything regarding kernel auditing. I have whatever the default behaviour is. I see that adding this to the workaround in comment 12 (this is the F23 flavor) echo '*Remove = "audit: PROCTITLE proctitle=[0-9A-F]+"' >> /etc/logwatch/conf/services/audit.conf suppresses those lines as well. Is there a reason why I shouldn't suppress PROCTITLE lines in the audit? Should I not be seeing those, and this is a misconfiguration that these are audited at all? Is there a more appropriate fix for the PROCTITLE lines than suppressing LogWatch reporting of them?
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm still seeing this in Fedora 25. audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' ... audit: NETFILTER_CFG table=security family=2 entries=0 ... and lots more. Steven, can you please re-open the bug and update to it Fedora 25? Thanks!
Thanks. Can you also re-open it? (Change the status)
Can someone tell me where to find a description of what this code is SUPPOSED to be doing? For instance what is an unmatched entry and why is it bad?
(In reply to Donald Cohen from comment #17) > Can someone tell me where to find a description of what this code is > SUPPOSED to be doing? For instance what is an unmatched entry and why is it > bad? An "Unmatched entry" is exactly what it sounds like -- an entry in the logfile for a service that doesn't match any logwatch rule. It's a log entry that fell through the cracks, so logwatch sends it in the nightly email. It's bad when the log is full of them, and they are "success" messages.. So logwatch gets filled with tons of messages saying, effectively, something that was supposed to happen did happen. That's an irrelevant entry for logwatch and hides any particular failure messages that might be there too.
To me unmatched suggested something like a start without a finish or vice versa, which was confusing since most of my unmatched entries actually come in start-finish pairs. The code seems to be full of cases that are to be ignored, such as if (( $ThisLine =~ /initializing netlink (socket|subsys) \(disabled\)/) or ( $ThisLine =~ /audit_pid=[0-9]* old=[0-9]*(?: by auid=[0-9]*)?/) or ... which I guess means that (1) the author of that code is confident that there can be no problem in a line that matches one of those patterns (I don't see any justification for that) (2) when I see hundreds of "unmatched" lines that don't seem particularly problematic I'm supposed to add a few patterns to the code Unless I'm supposed to recognize how the reported lines really ARE problematic I don't see what good they're doing me. It's also not clear to me whether success or failure are particularly relevant to what's worth reporting. All of this is why I was hoping for some documentation describing the design and justifications for logwatch, or at least these particular modules.
Just want to report back that I've substantially alleviated the problem on my system by inserting at line 138 of /usr/share/logwatch/scripts/services/audit: or ( $ThisLine =~ /comm="systemd"/) So whoever updates that file might consider some similar change? Also I did a yum update last night and this change got undone. I now have reinstalled it, but it would be nice if I didn't have to keep doing that. Is there some standard approved way of installing such changes that won't be undone? I'd still appreciate some documentation as described above.
Customized scripts go under /etc/logwatch/scripts/services and won't be replaced in an upgrade. These override the files in /usr/lib.
On my systems I have rpm -qf /usr/share/logwatch/scripts/services/audit logwatch-7.4.3-3.fc25.noarch What puzzles me is that on some systems I get this noise in the logwatch report and on some systems I don't, and I can't seem to figure out what the difference is. They all run the same version of Fedora (25 now, but the problem have persisted throughout several versions now) I don't see any .rpmnew or anything else indicating that the default files had changes, and the /usr/share/logwatch/scripts/services/audit files all have this md5sum: bd12578a9010d31fcca0ef59b91fbe5f /usr/share/logwatch/scripts/services/audit
Created attachment 1319784 [details] logwatch audit accept journald syntax This patch seems to fix logwatch audit results on f26. Old logwatch got its data from files in (usually) /var/log; now it gets it from the journal, with slightly different form. Also, "type=" is now a word, not a number. If $ThisLine matches the new format, it is transformed into the old format, while "type=" are changed to accept a word.
Created attachment 1319789 [details] cleaner logwatch audit accept journald syntax This patch seems to fix logwatch audit results on f26. Old logwatch got its data from files in (usually) /var/log; now it gets it from the journal, with slightly different format. Also, "type=" is now a word, not a number. If $ThisLine matches the new format, it is transformed into the old format, while "type=" are changed to accept a word.
I tested the patch, it solved the issue!
I'm still seeing this in Fedora 26
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Adding this line *Remove = "audit\[[0-9]+\]: \S+ pid=[0-9]+ uid=[0-9]+ auid=[0-9]+ ses=[0-9]+ subj=.*res=success" to audit.conf and this line *Remove = "dovecot\[[0-9]+\]: imap\(.*\): Logged out.*" to dovecot.conf of the logwatch services removed most of the noise for me.
(In reply to John Griffiths from comment #28) > Adding this line > > *Remove = "audit\[[0-9]+\]: \S+ pid=[0-9]+ uid=[0-9]+ auid=[0-9]+ ses=[0-9]+ > subj=.*res=success" > > to audit.conf and this line > > *Remove = "dovecot\[[0-9]+\]: imap\(.*\): Logged out.*" > > to dovecot.conf of the logwatch services removed most of the noise for me. These two lines fixed my logs. Thanks John Griffiths.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Guys, this is *still* relevant with Fedora 29. Can we please, please, please get the changes described above (which I am now using) into our logwatch packages?
@solomon Peachy I see at SF that they have dropped: logwatch-7.5.0 2018-12-28 perhaps also when a problem persists, as the close messafge indicates, bumping the version forward (here, from your report, to 29) is in order
I just updated to logwatch-7.5.1 from the Fedora 29 updates-testing repo to see what would happen. It did not fix the issue.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
There are hundreds of new messages in Logwatch reports in Fedora 31, of the forms xxx.service: Consumed n.nnns CPU time. xxx.service: Succeeded. and xxx.scope: Consumed n.nnns CPU time. xxx.scope: Succeeded.
Some of those were there already on f30, not sure if immediately after upgrade to f30 or with some update after that. My /etc/logwatch/conf/ignore.conf file now contains: session-.*\.scope: (Succeeded|Consumed) run-user-\d+.mount: Succeeded (service|socket): (Succeeded|Consumed) smb-.*.mount: Succeeded Lately it filters out about 250 lines.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still relevant in Fedora 31. I upgraded from f29 to f30 (skipping f30) and am now getting 1478 lines of session-nnnn.scope: Succeeded.: 1 Time(s) in my daily logwatch report. Likely most are from a per-minute cron job (24hr*60m=1440). Thumbs up to Henrique's suggestion in comment #38.