Hi Andreas,

Andreas Kusalananda wrote on Wed, Jan 22, 2020 at 08:58:26PM +0100:

> I mount my /usr/local directory from a remote server over NFS
> using amd(8).  This means that I have the directories directly
> beneath /usr/local appear on demand as symbolic links into
> /tmp_mnt/eeyore/vol/local/pooh where the /usr/local for the local
> machine "pooh" is mounted over NFS from "eeyore" (and mounted/unmounted
> on demand).
> 
> This works very well, but there is a handful of ports that misbehave
> with regards to manuals.  Of the 70 or so pre-built packages that I've
> installed on my amd64-current system, the only ones misbehaving are
> 
>       databases/pkglocatedb           (pkglocatedb-1.5)
>       devel/git,-main                 (git-2.25.0)
>       sysutils/p5-File-Rename-1.10    (p5-File-Rename-1.10)
> 
> When I do "man pkglocate", for example, I get
> 
> man: /tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1:
>      SYSERR: open: No such file or directory
> 
> ... and likewise for any other utility etc. from those ports.  Commands
> like "git clone --help" gives similar diagnostics.
> 
> The manuals are actually visible where they are supposed to be:
> 
> $ ls -l /usr/local/man/man1/{git{,-clone},pkg_locate}.1
> -rw-r--r--  1 root  bin  20005 Jan 20 22:20 /usr/local/man/man1/git-clone.1
> -rw-r--r--  1 root  bin  50901 Jan 13 19:49 /usr/local/man/man1/git.1
> -rw-r--r--  1 root  bin   2845 Jan 19 08:14 /usr/local/man/man1/pkg_locate.1
> 
> ... so it looks as if man(1) is, for whatever reason, looking in the
> wrong location for the file.

The man(1) manual page says:

  The mandoc.db(5) database is used for looking up manual page entries.
  In cases where the database is absent, outdated, or corrupt, man falls
  back to looking for files called name.section.

However, when the database is present and in the correct format but
references non-existent files like
  /tmp_mnt/eeyore/vol/local/pooh/man/usr/local/man/man1/pkg_locate.1
there is no fallback.  The reason is that by the time it turns out
the file name found in the database is bogus, man(1) has progressed
beyond the stage where it can repeat the search using a different
method.  Fallback to file system search only happens when no match
is found, not when the database contains a match but the path in
the database happens to be wrong.

> Manuals for other utilities, like rsync, pv, pwgen, openvpn, etc., do
> work as they should.

This sounds as if pkg_add(1) sometimes worked well but sometimes got
confused when running makewhatis(8) and consequently your database
is now corrupt in a weird way that i have never seen before.

Please show the output of

   $ man -w pkglocate rsync

The expected, correct result is

   $ man -w pkglocate rsync
  /usr/local/man/man1/pkg_locate.1
  /usr/local/man/man1/rsync.1

I expect you may see

  /tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1
  /usr/local/man/man1/rsync.1

I suspect if you run

   # makewhatis /tmp_mnt/eeyore/vol/local/pooh/man

the problem may go away, but after that, you may no longer be able
to reproduce the problem.  Also, the problem might re-emerge when
you install more packages because pkg_add(1) will run makewhatis(8)
on /usr/local/man, not on /tmp_mnt/... - and so will weekly(8).

In general, makewhatis(8) dislikes symbolic links pointing outside
the respective manpath and uses realpath(3) to normalize them,
then rejects the files if they aren't in a valid location.
What's a bit weird is that here it apparently accepted the files
but then somehow constructed wrong filenames anyway.

I might have to do some experimentation with symlinks to figure
out what exactly is going on.

You could also go to

  $ cd /usr/src/regress/usr.bin/mandoc/db/dbm_dump
  $ man mandoc.db
  $ man -l dbm_dump.1
  $ rm -f obj
  $ make cleandir
  $ make obj
  $ make cleandir
  $ make
  $ ./obj/dbm_dump /usr/local/man/mandoc.db | less

to look at the (probably) broken database in detail.

> I haven't created or changed any MAN* environment variables nor do I
> have a /etc/man.conf file.  I haven't been able to figure out what's
> special about the manuals for these ports.

I don't expect anything to be special about these ports; i suspect
that makewhatis(8) was run in a slightly different way or under
slightly different circumstances.  I'm not surprised that your
stunt of symnlinking /usr/local/man somewhere else turns out to be
fragile.

Yours,
  Ingo

Reply via email to