[OpenAFS] afsdb feature locking up afs_ioctl?

[Jeffrey Hutzelman]

On Monday, May 09, 2005 06:03:14 PM -0700 Mike Polek <mike@pictage.com> 
wrote:

> When the -afsdb flag is used for afsd, there appears to be
> an extra process that gets started to loop in the
> AfsdbLookupHandler function. (Process id 12269 below.)
> It looks like this process is holding /proc/fs/openafs/afs_ioctl
> open. Is this intended/necessary? Or an accidental side
> effect of something?

It's necessary.  That function spends most of its time blocked in an AFS 
system call, waiting for the AFS kernel module to need its services.  When 
the cache manager needs to have an AFSDB record looked up, the system call 
will return with details of the request; the AFSDB handler then does the 
lookup and makes another system call to return the result and wait for 
another request.  On recent Linux systems, AFS system calls are actually 
ioctls on /proc/fs/openafs/afs_ioctl.  So yes, this process is not only 
holding that file open but is actually blocked in an ioctl on it.


> The reason it's important to me is that
> I can't umount /proc while the process has the open file
> descriptor, and I need to umount /proc in order to properly
> get my system booted after a pivot_root.

I'm afraid afsd really wasn't intended to be started in this manner. 
However, there are a couple of options that might work for you:

(1) Extract AfsdbLookupHandler() and its dependencies into a separate
    program.  Run afsd without the -afsdb switch, and start the AFSDB
    handler in a separate program after you've pivoted the real root
    into place and remounted /proc.

(2) Instead of unmounting and remounting /proc, move the mounted tree
    with mount --move.  It should be possible to do this even while
    there are open files on the filesystem.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA