Bug 235307 - hcid keeps trying despite hopeless situation
hcid keeps trying despite hopeless situation
Product: Fedora
Classification: Fedora
Component: bluez-utils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
Depends On:
  Show dependency treegraph
Reported: 2007-04-04 19:15 EDT by Ulrich Drepper
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-10-04 11:31:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
bluez-utils-better-inotify-error.patch (1.14 KB, patch)
2007-10-04 11:26 EDT, Bastien Nocera
no flags Details | Diff

  None (edit)
Description Ulrich Drepper 2007-04-04 19:15:46 EDT
Description of problem:
Something changed in the SELinux policy in today update and hcid suddenly spits out

audit(1175727955.183:11107411): avc:  denied  { read } for  pid=1347 comm="hcid"
name="inotify" dev=inotifyfs ino=280 scontext=system_u:system_r:bluetooth_t:s0
tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir

Millions of lines, if you late it, and as fast as it can.  Yes, the policy
should be fixed, but the daemon should recognize that EPERM means there is no
hope and it should stop and not continue forever.

The machine basically ran in a busy loop and heated up and all this on a machine
with no bluetooth and no potential to have it (it's a xen domain).

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

How reproducible:
once was enough, thank you

Steps to Reproduce:
1.perform today (Apr 4 2007) update
Actual results:
hcid loops, constantly producing the above violation

Expected results:
hcid should recognize EPERM and stop

Additional info:
Comment 1 Bastien Nocera 2007-09-20 05:53:04 EDT
Do you know where in the hcid code the loop was going on?
Still a problem with recent bluez-utils updates?
Comment 2 Ulrich Drepper 2007-10-04 10:57:56 EDT
I don't know what loop it was and I think at the very least the SELinux policy
has been fixed.  If we cannot determine this it's likely better to just close it
until it breaks again.
Comment 3 Bastien Nocera 2007-10-04 11:26:15 EDT
Created attachment 215931 [details]

Add better error checking, avoid infinite looping

This should fix it, although, without a reproducer, I'm not sure it's so
useful. I'll send it upstream for feedback.
Comment 4 Bastien Nocera 2007-10-04 11:31:46 EDT
Patch discussion at:

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