Bug 247532 - Setroubleshoot keeps crashing
Summary: Setroubleshoot keeps crashing
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
(Show other bugs)
Version: 7
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-09 19:33 UTC by Jeroen Beerstra
Modified: 2008-06-17 01:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-17 01:50:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
signature.py patch to catch and report bad data (4.84 KB, patch)
2007-08-20 14:44 UTC, John Dennis
no flags Details | Diff
Exceptions logged as of 21st August 2007 (7.36 KB, text/plain)
2007-08-21 09:31 UTC, n0dalus
no flags Details
Rotated log messages from before the 18th Aug (7.64 KB, text/plain)
2007-08-21 18:22 UTC, n0dalus
no flags Details

Description Jeroen Beerstra 2007-07-09 19:33:50 UTC
Description of problem: The setroubleshhootd keeps crashing under a KDE session

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


How reproducible:

Steps to Reproduce:
1. service setroubleshhotd restart
2. start sealert
Actual results:

The setroubleshootd crashes after a while causing the sealert applet to loose
connection to the audit listener.

Expected results:

All should be running just fine

Additional info:


type=AVC msg=audit(1184008828.746:8901): avc:  denied  { getattr } for 
pid=10902 comm="setroubleshootd" name="kdecache-root" dev=dm-5 ino=1867996
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir

type=SYSCALL msg=audit(1184008828.746:8901): arch=c000003e syscall=4 success=no
exit=-13 a0=409fdcb0 a1=409fdd10 a2=409fdd10 a3=396d74b9d0 items=1 ppid=1
pid=10902 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=user_u:system_r:setroubleshootd_t:s0 key=(null)


2007-07-09 21:20:28,768 [program.ERROR] Can not handle AVC'S related to
dispatcher. exiting

setroubleshoot context=user_u:system_r:setroubleshootd_t:s0, AVC

Comment 1 Jeroen Beerstra 2007-07-09 22:28:34 UTC
It seems seedit made this one worse. However setroubleshootd did crash
occasionly before I ever heard of seedit, so not sure about the messages above
but will post any further messages, if any, when setroubleshootd crashes again.

Comment 2 Yuichi Nakamura 2007-07-31 00:52:09 UTC
Have you installed seedit?
seedit does not work with setroubleshoot.
And if you installed seedit and uninstalled it, 
boot at run level 3, and 
# fixfiles restore
(remove /tmp files, when you are asked)
and reboot.

Comment 3 Jeroen Beerstra 2007-07-31 21:31:31 UTC
Uninstalled seedit, removed the lines added to audit's config file, did a "touch
/.autorelabel" and rebooted and finally removed everyting in /var/tmp (/tmp is
tmpfs so this is not nescessary). All seems fine now.

Comment 4 n0dalus 2007-08-19 13:58:48 UTC
I am not running in enforcing mode, but setroubleshoot keeps crashing after a
short time running sealert.

  File "/usr/lib/python2.5/site-packages/setroubleshoot/analyze.py", line 379,
in auto_save_callback
  File "/usr/lib/python2.5/site-packages/setroubleshoot/analyze.py", line 357,
in save
    self.sigs.write_xml('sigs', self.filepath)
  File "/usr/lib/python2.5/site-packages/setroubleshoot/signature.py", line 612,
in write_xml
  File "/usr/lib/python2.5/site-packages/setroubleshoot/signature.py", line 571,
in get_xml_text_doc
    doc = self.get_xml_doc(obj_name)
  File "/usr/lib/python2.5/site-packages/setroubleshoot/signature.py", line 566,
in get_xml_doc
    root = self.get_xml_nodes(doc, obj_name)
  File "/usr/lib/python2.5/site-packages/setroubleshoot/signature.py", line 641,
in get_xml_nodes
    list.addChild(item.get_xml_nodes(doc, item_name))
  File "/usr/lib/python2.5/site-packages/setroubleshoot/signature.py", line 667,
in get_xml_nodes
    root.newChild(None, name, value)
  File "/usr/lib/python2.5/site-packages/libxml2.py", line 3270, in newChild
    ret = libxml2mod.xmlNewChild(self._o, ns__o, name, content)
TypeError: xmlNewChild() argument 4 must be string without null bytes or None,
not str

Comment 5 John Dennis 2007-08-20 14:40:56 UTC
RE comment #4: It appears as though some bad data is creeping in somehow and I
can't tell why from the traceback. I've modified the python source file
(signature.py) to catch the exception and log what the data was.

I'm not sure which version of setroubleshoot you're running. I've attached a
patch file for signature.py. If you're able please patch the file in
/usr/lib/python2.5/site-packages/setroubleshoot and when you get the traceback
please update this bugzilla with it.


Comment 6 John Dennis 2007-08-20 14:44:13 UTC
Created attachment 161884 [details]
signature.py patch to catch and report bad data

Comment 7 n0dalus 2007-08-21 09:28:49 UTC
Here is the version of setroubleshoot and possibly related packages:


Attaching log file with exceptions generated so far.

Comment 8 n0dalus 2007-08-21 09:31:12 UTC
Created attachment 161953 [details]
Exceptions logged as of 21st August 2007

Comment 9 John Dennis 2007-08-21 15:43:58 UTC
Thank you, but unfortunately the attachment does not have the logging
information that was added by the patch. After applying the patch did you
restart the service?

% service setroubleshoot restart

You should be seeing lines that start something like this:

2007-08-21 11:33:12,457 [xml.ERROR] 

Also, it looks like the attachment data came from syslog because it has line
endings stripped and the message is truncated to a maximum line lenght.
Unforutantely with traceback data that means part of traceback is almost always
truncated. Setroubleshoot does log to its own log file
(/var/log/setroubleshoot/setroubleshootd.log) and the contents of that log file
are unmodified yielding the complete contents of the message. Having said all
that, in this case all I really need is the contents of the line after [xml.ERROR]

Once again, thanks for your help.

Comment 10 n0dalus 2007-08-21 18:07:22 UTC

I did restart the service, and something went wrong with setroubleshoot today
but there is nothing in the /var/log/setroubleshoot/setroubleshootd.log file
except "2007-08-22 03:28:51,945 [email.WARNING] cannot open file
/var/lib/setroubleshoot/email_alert_recipients, No such file or directory".

It doesn't seem to be "crashing" completely. It hangs around but just stops
doing anything useful (sealert can't connect to it, and it stops logging
anywhere -- syslog shows no selinux messages even though I have a cron job
causing an AVC message every 5 minutes).

By the looks of my logs, it "crashed" with that [rpc.ERROR] exception
parserError in my syslog. Why didn't it log anything to its log file about that?

Comment 11 n0dalus 2007-08-21 18:22:23 UTC
Created attachment 161994 [details]
Rotated log messages from before the 18th Aug


Noticed that the rotated log setroubleshootd.log.1 from the 18th August has
some more error messages that might help, so I am attaching it.

I noticed the config file had an option to append to the log instead of
truncating it. I am using that now, so hopefully whatever gets logged won't be
accidentally lost again when the service restarts.

Comment 12 n0dalus 2007-08-24 11:37:36 UTC
Got a different crash message this time:

2007-08-24 09:59:24,695 [avc.ERROR] Plugin Exception plugins.httpd_bad_labels
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/setroubleshoot/analyze.py", line 259,
in analyze_avc
  File "/usr/lib/python2.5/site-packages/setroubleshoot/server.py", line 157, in
    _(" For complete SELinux messages. run sealert -l %s" % siginfo.local_id ))
UnicodeDecodeError: 'ascii' codec can't decode byte 0x85 in position 80: ordinal
not in range(128)

That was all I found in /var/log/setroubleshoot/setroubleshootd.log

/var/log/messages had an extra error just before this one that setroubleshoot
didn't put in its log (once again truncated):

[rpc.ERROR] exception parserError: xmlParseDoc() failed Traceback (most recent
call last):   File "/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py",
line 780, in handle_client_io     self.receiver.feed(data)   File
"/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 621, in feed    
self.process()   File "/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py",
line 613, in process     self.dispatchFunc(self.header, self.body)   File
"/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 811, in
default_request_handler     self.handle_return(type, rpc_id, body)   File
"/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 794, in
handle_return     interface, method, args = convert_rpc_xml_to_args(body)   File
"/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 145, in
convert_rpc_xml_to_args     doc = libxml2.parseDoc(cmd)   File
"/usr/lib/python2.5/site-packages/libxml2.py", line 1264, in parseDoc     if ret
is None:raise parserError('xmlPars

Comment 13 John Dennis 2007-08-27 17:17:48 UTC
from comment #12 I presume you're running with a default language other than
english. There was a known bug which caused xml errors due to i18n strings not
being properly exchanged. Please try upgrading to setroubleshoot-1.10.1-1.fc7
which is in testing updates and see if this resolves your problem. Thank you.

Comment 14 n0dalus 2007-08-28 12:47:40 UTC
[root@gateway ~]# yum --enablerepo=updates-testing update setroubleshoot
Loading "presto" plugin
Setting up Presto
[Errno 4] IOError: [Errno ftp error] 421 Sorry, mirror already has 21 users
logged on.  Try again in 10 minutes.
Trying other mirror.
updates-testing           100% |=========================| 1.9 kB    00:00     
livna                     100% |=========================| 2.1 kB    00:00     
fedora                    100% |=========================| 2.1 kB    00:00     
adobe-linux-i386          100% |=========================|  951 B    00:00     
updates                   100% |=========================|  383 B    00:00     
Reading Presto metadata in from local files
Setting up Update Process
updates                   100% |=========================| 1.9 kB    00:00     
Resolving Dependencies
--> Running transaction check
---> Package setroubleshoot.noarch 0:1.10.1-1.fc7 set to be updated
--> Processing Dependency: setroubleshoot-server = 1.10.1-1.fc7 for package:
--> Processing Dependency: setroubleshoot-plugins for package: setroubleshoot
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package setroubleshoot-server.noarch 0:1.10.1-1.fc7 set to be updated
---> Package setroubleshoot.noarch 0:1.10.1-1.fc7 set to be updated
--> Processing Dependency: setroubleshoot-plugins for package: setroubleshoot-server
--> Processing Dependency: setroubleshoot-plugins for package: setroubleshoot
--> Finished Dependency Resolution
Error: Missing Dependency: setroubleshoot-plugins is needed by package
Error: Missing Dependency: setroubleshoot-plugins is needed by package

Comment 15 Bug Zapper 2008-05-14 13:28:55 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 WONTFIX if it remains open with a Fedora 'version' of '7'.

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 prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 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 please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Bug Zapper 2008-06-17 01:50:26 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 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.

Thank you for reporting this bug and we are sorry it could not be fixed.

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