Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 227315 - sealert doesn't seem to work if auditd/audispd is restarted
sealert doesn't seem to work if auditd/audispd is restarted
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: John Dennis
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2007-02-05 00:59 EST by James Antill
Modified: 2008-01-09 14:25 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-09 14:25:43 EST
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 James Antill 2007-02-05 00:59:38 EST
Description of problem:

 If I restart auditd/audispd then setroubleshootd reconnects, and I'm getting
sealerts in /var/log/messages ... but I don't seem to be getting the GUI panel
updates, I'm not 100% but I think I should be.
 strace on the sealert -s shows:

ioctl(9, FIONREAD, [0])                 = 0
poll( <unfinished ...>

...I'll update if it comes back.
Comment 1 James Antill 2007-02-05 01:00:39 EST
 Removing some of the options I'd left on. Sorry steve.
Comment 2 James Antill 2007-02-05 01:03:21 EST
 Well, waiting a while longer I've got a bunch of lines like:

poll([{fd=9, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}, {fd=17,
events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=10,
events=POLLIN|POLLPRI}, {fd=8, events=POLLIN}, {fd=3, events=POLLIN}], 7, -1) = 1
ioctl(9, FIONREAD, [32])                = 0
read(9, "p\0\30\313\1\0\300\1\236$\340\2\1\0\0\0\0\33~\220\364\32"..., 32) = 32
ioctl(9, FIONREAD, [0])                 = 0

...so something is certainly happening. But I'm still getting sealert messages
in /var/log/messages and nothing in my panel notify area.
Comment 3 James Antill 2007-02-05 08:03:17 EST
 So after still getting the sealert messages this morning I looked again at the
running procs. and discovered:

% ps axuwZ | egrep trouble
system_u:system_r:setroubleshootd_t root  2064  0.0  0.8  43112 12780 ?       
Ssl  Feb01   0:08 /usr/bin/python -E /usr/sbin/setroubleshootd
root:system_r:unconfined_t      root     31236  0.4  0.8  44192 13856 ?       
Ssl  00:37   1:52 /usr/bin/python -E /usr/sbin/setroubleshootd restart

...so this bug might only occur when you restart and go from having
setroubleshoot transition to not-transition. Doing a sertvice stop/service start
and then manually kill'ing the old version has got rid of the messages, anyway.

Comment 4 John Dennis 2007-08-27 14:28:42 EDT
I'm confused, I don't see how setroubleshootd could ever have been started with
the 'restart' option which is showing up in the ps output, that's not what the
init.d script does on a service restart. It looks like somehow you got two
copies of setroubleshootd running which would be a problem. 

I just tested service start, service restart, and service stop with current
versions and I don't see any problems.

Do you still believe this is a current bug?
Comment 5 John Dennis 2008-01-09 14:25:43 EST
closing as the requested information has not been provided. Also the whole
mechanism of how setroubleshoot and sealert interact has been rewritten since
this bug was originally filed (for example sealert now listens on the dbus
system bus for changes in the running status of setroublehsootd).

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