mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Colby Kraybill <colby@astro.berkeley.edu>
To: linux-kernel@vger.kernel.org
Subject: Bad Descriptor error (autofs/nfs)
Date: Sun, 3 Nov 2002 17:36:28 -0800 (PST)	[thread overview]
Message-ID: <Pine.GSO.4.44.0211031717220.768-100000@celestial> (raw)


Hello,

I am attempting to integrate some RedHat 7.3 based Linux machines
into a pre-existing network of ~150 sunsparc solaris machines.

I have run across an odd problem which did not yield to many
google web and usetnet searches.

Here's the problem:

I am logged into the machine and everything  seems to work
fine interoperating with the solaris machines.  User directories
are mounted via NFS (using autofs), so, I try to do an ls of another
user's directory and get the following:

% ls ~user
ls: write error: Bad file descriptor

I can cd ~user and run ls and it works fine, I see the
files in the user's directory.
If I cd ~ and then do the ls ~user again, it works fine,
I see the files in the user's directory.  So, it's as if
some table somewhere isn't properly uptodate on the
intial ls.

When I run strace on both instances, I see everything
looking about the same (except for some pointers and
file descriptor numbers being different) up to this
point:

ioctl(1, SNDCTL_TMR_TIMEBASE, 0xbffff550) = -1 EBADF (Bad file descriptor)
ioctl(1, 0x5413, 0xbffff618)            = -1 EBADF (Bad file descriptor)

Under the "correctly" working one, I see this:

ioctl(1, SNDCTL_TMR_TIMEBASE, 0xbffff560) = -1 ENOTTY (Inappropriate ioctl
for device)
ioctl(1, 0x5413, 0xbffff628)            = -1 ENOTTY (Inappropriate ioctl
for device)

In the case of the Bad descriptor, there are more error messages
further into ls that also return EBADF, but there are _no_ EBADF's in
the "correctly" running one.

Here is why I think this might be a kernel related problem:

I am running autofs.  When I do the ls ~user, the correct
disk does get mounted, but it will still return the EBADF
message.  When I cd into the directory, and do the ls,
it works fine.  And from that point on, I can ls ~user
with impunity, unless I let the automounter unmount
the disk automatically.  Then the same thing starts
happening.  Perhaps there is something in the way that
the file system routines are failing to
create a fully proper file descriptor until some other
init routine runs by cd'ing to the disk (causing
a different cascade of stat's to be executed?)

The autofs version is autofs-3.1.7-28

Other important information:

I am using nis+.  The user information is coming from
the nis+ server. The nis utils are version 1.4.1

Output of ver_linux:

Linux lynx 2.4.18-17.7.xcustom #2 Mon Oct 28 13:15:36 PST 2002 i686
unknown

Gnu C                  2.96
Gnu make               3.79.1
util-linux             2.11n
mount                  2.11n
modutils               2.4.14
e2fsprogs              1.27
reiserfsprogs          3.x.0j
PPP                    2.4.1
isdn4k-utils           3.1pre1
Linux C Library        2.2.5
Dynamic linker (ldd)   2.2.5
Procps                 2.0.7
Net-tools              1.60
Console-tools          0.3.3
Sh-utils               2.0.11
Modules Loaded         binfmt_misc vmnet parport_pc parport vmmon autofs
nfs lockd sunrpc natsemi ipchains ide-cd cdrom ext3 jbd
usb-uhci usbcore

Thanks in advance for any advice on this.

---------------------------------------------------------------------
James Colby Kraybill                       Radio Astronomy Laboratory
colby@astro.berkeley.edu           University of California, Berkeley





                 reply	other threads:[~2002-11-04  1:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.44.0211031717220.768-100000@celestial \
    --to=colby@astro.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®