Bug 247532

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.

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.

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.

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

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.

Created attachment 161884 [details]
signature.py patch to catch and report bad data

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.

Created attachment 161953 [details]
Exceptions logged as of 21st August 2007

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.

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?

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.

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

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.

[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

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

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.