Comment 10 for bug 1001189

On Sat, May 19, 2012 at 13:15:48 -0000, Paul Crawford wrote:
> Actually it is slightly more bizarre, that NIS account (opr) is braking
> 'man' but another NIS account on the 12.04 machine is OK, while opr (and
> others) accounts are all OK on my 10.04 box, so maybe there is some
> environment value, etc, that causes opr on the 12.04 box to access
> /packages/local/share/man/index.db which is triggering the fault.

> But why is it seeking so far?

> If the version of DB was wrong, is there not some header value to flag
> this?

Yes, it seems like there are two separate (but related) questions here:
  1) why does the one NIS-account-on-Precise have this problem but not
     your others?

  2) why is man/gdbm trying to seek past the end of the file
     (and failing in such an unhelpful way when it does)?

As far as the first question: Does "/packages/local/share/man/" get opened
and/or stat-ed in the strace when you run "man" on the Lucid box and from
other accounts on the Precise box?

Is $MANPATH set differently in the different accounts?

Is /packages/local/ a shared network mount available on the Lucid box, too
(or something like that), or is it unique to the Precise box?

What are the access permissions on the directories in the
/packages/local/share/man path? (I'm wondering if somehow "opr" is the only
one able to access that index.db file?)

I don't have a lot of ideas about the second question, but I notice that
"file" gives me the following for the standard index.db file:

  $ file /var/cache/man/index.db
  /var/cache/man/index.db: GNU dbm 1.x or ndbm database, little endian

What does it report for your /packages index.db file?

      Nathan