Bug 201902 - audispd: s == 0 - repeated 12 times
audispd: s == 0 - repeated 12 times
Product: Fedora
Classification: Fedora
Component: audit (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-08-09 14:22 EDT by Robert Scheck
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-22 10:29:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2006-08-09 14:22:46 EDT
Description of problem:
Aug  9 19:56:25 tux auditd[10838]: Init complete, auditd 1.2.5 listening for 
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):

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 17:09:20 EDT
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 03:07:22 EDT
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 10:29:26 EDT
This is fixed in the current release.

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