Bug 880815 - Drift detection hangs on reading named pipes on filesystem
Drift detection hangs on reading named pipes on filesystem
Status: NEW
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.2
Unspecified Unspecified
unspecified Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks: 798006
  Show dependency treegraph
 
Reported: 2012-11-27 15:27 EST by Larry O'Leary
Modified: 2012-11-27 15:27 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 798006
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Larry O'Leary 2012-11-27 15:27:02 EST
+++ This bug was initially created as a clone of JBoss ON Bug #798006 +++

Description of problem:  Drift detection hangs on special 'fifo' files with 'prw' file permissions.  Issue detected as part of verifying https://bugzilla.redhat.com/show_bug.cgi?id=789454


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


How reproducible:  100% by mfoley and jshaughn


Steps to Reproduce:
1.  Setup a Drift Definition on a directory, such as '/tmp' that contains files with permissions 'prw'

2.  Click the button to detect drift.
3.  Drift hangs.  Snapshot #0 is never created.
  
Actual results:  Drift detection hangs.


Expected results:  Snapshot #0 is created and problematic filetypes are avoided in a robust manner.


Additional info:

[root@foleymonsterbox1 icedteaplugin-mfoley]# ls -al
<mfoley> total 24
<mfoley> drwx------.  2 mfoley mfoley  4096 Jan 13 16:40 .
<mfoley> drwxrwxrwt. 42 root   root   20480 Feb 27 13:23 ..
<mfoley> prw-------.  1 mfoley mfoley     0 Jul 12  2011 24966-icedteanp-appletviewer-to-plugin
<mfoley> prw-------.  1 mfoley mfoley     0 Jul 12  2011 24966-icedteanp-plugin-to-appletviewer
<mfoley> prw-------.  1 mfoley mfoley     0 Jun  2  2011 2564-icedteanp-appletviewer-to-plugin
<mfoley> prw-------.  1 mfoley mfoley     0 Jun  2  2011 2564-icedteanp-plugin-to-appletviewer
<mfoley> prw-------.  1 mfoley mfoley     0 Jan 13 16:44 29849-icedteanp-appletviewer-to-plugin
<mfoley> prw-------.  1 mfoley mfoley     0 Jan 13 16:44 29849-icedteanp-plugin-to-appletviewer

--- Additional comment from Mike Foley on 2012-02-27 17:05:53 EST ---

this is an edge case that can be avoided with includes/excludes ... in the unlikely situation that someone wants to monitor a directory with these unusual file types 

preliminary discussion with developer indicated the fix could be a bit heavy-handed to open every file to see if it is actually readable (btw, trying to read this named pipe file is what causes drift to hang) 

re inclusion into JON 3.01 (we are past code freeze now, and in the endgame) 
-is it a regression?  NO
-is it a customer issue?  NO
-is it urgent?
-is it a main line primary use-case?  NO


ergo, recommend a push of target release to jon 3.1 or later.

--- Additional comment from Mike Foley on 2012-02-27 18:51:46 EST ---

documenting that i tested drift on directories with symbolic links ... and that worked.

--- Additional comment from Mike Foley on 2012-03-05 11:39:56 EST ---

JON 3.1 medium priority, per triage meeting (crouch, foley, loleary)

--- Additional comment from Ian Springer on 2012-05-14 17:08:26 EDT ---

I think the solution to this, would be to change th following code in DriftDetector.doDirectoryScan():


  if (!file.canRead()) {
                            if (log.isDebugEnabled()) {
                                log.debug("Skipping " + file.getPath() + " since we do not have read access.");
                            }
                            return;
                        }

to:

  if (!file.isFile()) {
                            if (log.isDebugEnabled()) {
                                log.debug("Skipping " + file.getPath() + " since it is not a regular file.");
                            }
                            return;
                        }

Since File.isFile() should only return true for regular files or symlinks to regular files, which I believe are the only things we care about.

I'm assigning this to Jay, since he worked on the related bug 789454, so he can comment.

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