Cd to nonexistent directory in /proc

Patrick O'Callaghan pocallaghan at gmail.com
Sat Jun 18 04:38:42 UTC 2011


On Sat, 2011-06-18 at 13:04 +1000, Cameron Simpson wrote:
> On 17Jun2011 20:12, Kevin Martin <kevintm at ameritech.net> wrote:
> | On 06/17/2011 07:16 PM, Patrick O'Callaghan wrote:
> | > On Fri, 2011-06-17 at 15:03 -0700, Jonathan Ryshpan wrote:
> | >> Investigating a hanging instance of googleearth (wich process number
> | >> 3110), I noticed that it's possible to 
> | >> 	cd /proc/3110
> | >> while on the other hand
> | >> 	ls /proc
> | >> does not show 3110 as being in the proc directory.
> | >>
> | >> Any ideas what's going on?
> | > I can't imagine how that could happen, unless the directory entry
> | > disappeared between you doing the cd and the ls, perhaps because the
> | > process terminated. OTOH is you can reproduce this reliably, it could
> | > merit a Bugzilla report.
> | >
> | > poc
> | >
> | 
> | It's a kernel / system call bug somewhere.  We ran (the company I work for) into this exact bug in our software application (a
> | monitoring tool for monitoring system health, applications, doing log file scraping).  Monitoring of processes worked on AIX,
> | Solaris, etc. but with a version of Linux starting about 3-4 years ago, it stopped working reliably.  It has to do with a system
> | call and I can't remember at this time what it was.  I'll look back on our application fixes and see if I can come up with what the
> | fix was.  It might absolutely merit a Bugzilla.
> 
> [speculation...]
> It might be raciness in the readdir calls. I'd imagine /proc is rather
> volatile becuase of all the PIDs. Readdir has always been a weak link in
> the directory listing stuff (not just Linux, though it or GNU ls might
> be particularly prone to exposing it).
> [/speculation]

The problem might be similar to this:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/broken-out/proc-readdir-race-fix-take-3.patch

poc



More information about the users mailing list