Bug 201902 - audispd: s == 0 - repeated 12 times
Summary: audispd: s == 0 - repeated 12 times
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: audit
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-09 18:22 UTC by Robert Scheck
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-08-22 14:29:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Robert Scheck 2006-08-09 18:22:46 UTC
Description of problem:
[...]
Aug  9 19:56:25 tux auditd[10838]: Init complete, auditd 1.2.5 listening for 
events
Aug  9 19:56:25 tux audispd: starting audispd
Aug  9 19:56:25 tux audispd: s == 0
Aug  9 20:08:07 tux last message repeated 2 times
Aug  9 20:17:15 tux audispd: s == 0
Aug  9 20:19:25 tux last message repeated 2 times
Aug  9 20:22:53 tux last message repeated 12 times
[...]

Version-Release number of selected component (if applicable):
audit-1.2.5-7

How reproducible:
Everytime, just install -7 and have a look into syslog.

Actual results:
Repeating message "audispd: s == 0"

Expected results:
Silence like before ;-)

Comment 1 Steve Grubb 2006-08-14 21:09:20 UTC
Dan removed some debug statements for the -7 release. I just looked at the
source code in -7 and I do not see what would be causing the message. Can you
just verify that -7 installed correctly and you aren't running -6 by accident.
rpm -q --verify audit might also be a good datapoint. Thanks.

Comment 2 Robert Scheck 2006-08-15 07:07:22 UTC
Well, audit rpm packaging is somewhere insane, because mTime always differs, 
even after rm -f /etc/audit/auditd.conf and forced rpm re-installation of the 
audit package:

# rpm -V audit audit-libs audit-libs-devel audit-libs-python
.......T c /etc/audit/auditd.conf
# 

Ah and I removed the mcstrans package because as result of bug #195916 (of 
course there was an improvement, but it is very far from perfect anyway). I
was brought to this because of "s == 0" which maybe could come from "s0"?
But if message is triggered by missing mcstrans package, this should be fixed,
because not everybody really wants to use the CPU-wasting mcstrans daemon ;-)

Comment 3 Daniel Walsh 2006-08-22 14:29:26 UTC
This is fixed in the current release.


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