Bug 880815

Summary: Drift detection hangs on reading named pipes on filesystem
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: driftAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.2CC: loleary, mfoley
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: ---
Bug Depends On:    
Bug Blocks: 798006    

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.