Bug 308281 - sealert fails to start with undefined symbol: fsetfilecon_raw
sealert fails to start with undefined symbol: fsetfilecon_raw
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-09-26 21:29 EDT by dex
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-28 12:06:49 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 dex 2007-09-26 21:29:45 EDT
Description of problem:
sealert fails to start with undefined symbol: fsetfilecon_raw error

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

How reproducible:

Steps to Reproduce:
1.sealert -b
Actual results:
sealert -b
Traceback (most recent call last):
  File "/usr/bin/sealert", line 104, in <module>
    from setroubleshoot.analyze import *
  File "/usr/lib/python2.5/site-packages/setroubleshoot/analyze.py", line 29, in
    from setroubleshoot.avc_audit import *
  File "/usr/lib/python2.5/site-packages/setroubleshoot/avc_audit.py", line 28,
in <module>
    import selinux
  File "/usr/lib/python2.5/site-packages/selinux.py", line 7, in <module>
    import _selinux
ImportError: /usr/lib/python2.5/site-packages/_selinux.so: undefined symbol:

Expected results:
to see browser

Additional info:
I haven't run sealert in f7 due to this bug #237134 and as it was a duplicate of
another bug which was recently closed, I gave it a go again this time it crashes
out before starting. kde desktop
Comment 1 dex 2007-09-26 22:14:30 EDT
Things just changed due to koji :-)

rpm -q rpm -q selinux-policy-targeted selinux-policy setroubleshoot
setroubleshoot-server libselinux libselinux-devel libselinux-python


[root@dexterFC ~]# sealert -b
Traceback (most recent call last):
  File "/usr/bin/sealert", line 107, in <module>
    from setroubleshoot.analyze import *
  File "/usr/lib/python2.5/site-packages/setroubleshoot/analyze.py", line 28, in
    from setroubleshoot.avc_audit import *
  File "/usr/lib/python2.5/site-packages/setroubleshoot/avc_audit.py", line 49,
in <module>
    my_context = AvcContext(selinux.getcon()[1])
TypeError: getcon() takes exactly 1 argument (0 given)

Comment 2 John Dennis 2007-09-27 10:50:39 EDT
Thank you for reporting this.

The problem is in libselinux, there was a bad build and the swig bindings did
not update properly. Many of the entry points in libselinux-python-2.0.14-8.fc7
have an extra parameter which should not be there. A new build is being prepared
and should be available shortly in koji.

Changing the component to libselinux and owner to dwalsh.
Comment 3 dex 2007-09-27 14:43:54 EDT
ok thanks for adjusting to right component and generally pointing me in the
right direction :-)

grabbed these from koji:


the browser starts with sealert -S but cannot connect to 

trying to start and restart setroubleshoot from system-config-services brings up
an error dialog with no info.
Comment 4 dex 2007-09-27 14:50:24 EDT
This is in logs after failure.

Sep 27 19:47:41 dexterFC setroubleshoot: [rpc.ERROR] attempt to open server
connection failed: No such file or directory

Comment 5 Daniel Walsh 2007-09-27 15:10:27 EDT
Are you seeing avc errors?
Comment 6 dex 2007-09-27 15:23:52 EDT
no avc's in audit.log
Comment 7 dex 2007-09-27 15:25:54 EDT
bugzilla is back!
to be clear no avc denials in audit.log
Comment 8 Daniel Walsh 2007-09-27 15:45:48 EDT
I think you also need selinux-policy-2.6.4-45.fc7.src.rpm
  Which should be going in fedora-testing.
Comment 9 dex 2007-09-27 18:14:18 EDT
Yep got it see comment #1 
Comment 10 John Dennis 2007-09-27 18:54:25 EDT
see comment #12 in bug 289371, you may be hit by the same thing.

From your description it sounds like the setroubleshootd daemon is not starting.
If after the reboot that the above bugzilla suggests the problem persists then
please check the contents of /var/log/setroubleshoot/setroubleshootd.log and see
if there are tracebacks or error messages, if not we can try running the daemon
in the foreground in verbose mode, but lets try the other options first.

Comment 11 dex 2007-09-28 12:06:49 EDT
ok sorry for the noise I forgot to turn selinux back on! a reboot and relabel
later and everything is fine. closing this bug before any one notices :-)  

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