Bug 247532 - Setroubleshoot keeps crashing
Setroubleshoot keeps crashing
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
7
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: John Dennis
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-09 15:33 EDT by Jeroen Beerstra
Modified: 2008-06-16 21:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:50:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 10:44 EDT, John Dennis
no flags Details | Diff
Exceptions logged as of 21st August 2007 (7.36 KB, text/plain)
2007-08-21 05:31 EDT, n0dalus
no flags Details
Rotated log messages from before the 18th Aug (7.64 KB, text/plain)
2007-08-21 14:22 EDT, n0dalus
no flags Details

  None (edit)
Description Jeroen Beerstra 2007-07-09 15:33:50 EDT
Description of problem: The setroubleshhootd keeps crashing under a KDE session

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

setroubleshoot-1.9.4-2.fc7
setroubleshoot-server-1.9.4-2.fc7

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:

/var/log/audit/audit.log

type=AVC msg=audit(1184008828.746:8901): avc:  denied  { getattr } for 
pid=10902 comm="setroubleshootd" name="kdecache-root" dev=dm-5 ino=1867996
scontext=user_u:system_r:setroubleshootd_t:s0
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)

/var/log/setroubleshoot/setroubleshootd.log

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
scontext=user_u:system_r:setroubleshootd_t:s0
Comment 1 Jeroen Beerstra 2007-07-09 18:28:34 EDT
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-30 20:52:09 EDT
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 17:31:31 EDT
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 09:58:48 EDT
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
    self.save()
  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
    f.write(self.get_xml_text_doc(obj_name))
  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 10:40:56 EDT
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.

Thanks.
Comment 6 John Dennis 2007-08-20 10:44:13 EDT
Created attachment 161884 [details]
signature.py patch to catch and report bad data
Comment 7 n0dalus 2007-08-21 05:28:49 EDT
Here is the version of setroubleshoot and possibly related packages:

setroubleshoot-1.9.4-2.fc7
setroubleshoot-server-1.9.4-2.fc7
audit-1.5.3-1.fc7
kernel-2.6.22.1-41.fc7
selinux-policy-targeted-2.6.4-33.fc7
selinux-policy-2.6.4-33.fc7
libselinux-2.0.14-4.fc7

Attaching log file with exceptions generated so far.
Comment 8 n0dalus 2007-08-21 05:31:12 EDT
Created attachment 161953 [details]
Exceptions logged as of 21st August 2007
Comment 9 John Dennis 2007-08-21 11:43:58 EDT
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 14:07:22 EDT
Hi,

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 14:22:23 EDT
Created attachment 161994 [details]
Rotated log messages from before the 18th Aug

Hi,

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 07:37:36 EDT
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
    report_receiver.report_problem(report)
  File "/usr/lib/python2.5/site-packages/setroubleshoot/server.py", line 157, in
report_problem
    _(" 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 13:17:48 EDT
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 08:47:40 EDT
[root@gateway ~]# yum --enablerepo=updates-testing update setroubleshoot
Loading "presto" plugin
Setting up Presto
ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/updates/testing/7/i386/repodata/repomd.xml:
[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:
setroubleshoot
--> 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
setroubleshoot
Error: Missing Dependency: setroubleshoot-plugins is needed by package
setroubleshoot-server
Comment 15 Bug Zapper 2008-05-14 09:28:55 EDT
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:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2008-06-16 21:50:26 EDT
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.