[OpenAFS] afsdb feature locking up afs_ioctl?
Mon, 09 May 2005 21:39:57 -0400
On Monday, May 09, 2005 06:03:14 PM -0700 Mike Polek <firstname.lastname@example.org>
> 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) <email@example.com>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA