On Sat, Jan 25, 2020 at 03:07:00AM +0100, Ingo Schwarze wrote:
> Hi Andreas,
Good morning Ingo,
See below.
>
> 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
$ man -w pkglocate rsync
/tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1
/tmp_mnt/eeyore/vol/local/pooh/man/man1/pkg_locate.1
/tmp_mnt/eeyore/vol/local/pooh/man/man1/rsync.1
>
> 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
Yes, but with the *correct* entry for pkg_locate.1 also present after
the first bogus one.
>
> I suspect if you run
>
> # makewhatis /tmp_mnt/eeyore/vol/local/pooh/man
Yes, this corrects the database:
$ man -w pkglocate rsync
/tmp_mnt/eeyore/vol/local/pooh/man/man1/pkg_locate.1
/tmp_mnt/eeyore/vol/local/pooh/man/man1/rsync.1
The command
# makewhatis /usr/local/man
also corrects the database. As does running makewhatis with no
arguments.
>
> 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).
Since running makewhatis on /usr/local/man (and actually also without
a directory argument at all) corrects the database, I expect that the
/etc/weekly script will actually correct the issue on my other machines,
rather than corrupt the database with bogus entries.
The issue seems to arise from the pkg_* tools.
Here I've made sure that rsync is not installed and that the manual
database is correct:
$ man -w rsync
man: No entry for rsync in the manual.
$ doas pkg_add -D snap rsync
doas (k...@pooh.prefix.duckdns.org) password:
quirks-3.216 signed on 2020-01-24T11:25:24Z
Ambiguous: choose package for rsync
a 0: <None>
1: rsync-3.1.3
2: rsync-3.1.3-iconv
Your choice: 1
rsync-3.1.3: ok
The following new rcscripts were installed: /etc/rc.d/rsyncd
See rcctl(8) for details.
$ man -w rsync
/tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/rsync.1
$ doas makewhatis
$ man -w rsync
/tmp_mnt/eeyore/vol/local/pooh/man/man1/rsync.1
The thing that pkglocate, git and p5-File-Rename have in common, I
realize now, is that they were all installed, reinstalled, or updated
during the last week.
>
> 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 think the issue may possibly be with some path construction within the
bowels of pkg_add.
>
> 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.
It may be a bit of a stunt, but I don't think it's too far fetched to
have /usr/local mounted remotely via amd(8), just like it ought to
be "normal" to mount /home in the same way (which I do). What doing
this gives me is the ability to have machines with only a 2 GB chunk
of disk for the base system while everything "extra" is mounted from a
fileserver. Using amd(8) for this is convenient. Using persistent NFS
mounts would also be an option, obviously.
Since running makewhatis solves this local issue for me (thanks for
that!), and since I *believe* that /etc/weekly will not corrupt the
manual database further, I'm more or less content with letting this
slide.
>
> Yours,
> Ingo
With kind regards,
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
