Arch Linux

Perhaps it is needed to force the rebuid of the database once (mandb -c) before this issue appears.

Just testet it. Rebuilding the database does not help. mandb still thinks it has to be rebuilt.

I did not say that rebuilding helps. Downgrading man-pages to a version less than 3.20 does.
BTW: 3.20 is outdated, too. I marked it in the repo. Perhaps this also fixes that.

I can comfirm this problem. I do a test with man-pages 3.21 without the poxis man pages and all works fine.

Question: Is there a reason why we include the poxis man pages instead of seperates packages?

Note: In the cronjob i put a "nice -n 19 ionice -c 3" before "/usr/bin/mandb --quiet" which is the same as opensuse do it in their cronjob.

Please run mandb with --debug (and without --quiet) and attach the output.

mandb -d > mandb.log 2>&1

OK. Could you now attach the following three files:

/var/cache/man/index.db
/usr/share/man/man3/acoshl.3p.gz
/usr/share/man/man3/acosh.3p.gz

(I think I know what's happening now; acoshl(3p) is apparently a .so reference to acosh(3p) but mandb is only recording acosh(3p) as a "ghost" whatis reference, and then getting confused when it sees it as a real file. However, I don't have an Arch Linux system myself to test this directly, and hope that the above files will give me enough material to reproduce this directly and test a fix.)

Thanks for helping

Colin, any progress?

It took me a while to reproduce this since it turned out I needed to have acosh.3.gz as well as acosh.3p.gz, and it seemed to depend on the exact order in which mandb processed these files. A simplified manual page tree sufficient to reproduce the problem is acosh(3) as a real page, acosh(3p) as a real page, and acoshl(3p) as a .so link pointing to acosh(3p), and a version of mandb hacked to process the pages in that order regardless of what readdir() returns. A detailed technical explanation follows. First, Andreas, here's the change I believe you need to fix this bug (you'll see from the revision history that it took me a few goes, largely because it's very late at night here):

http://bzr.savannah.gnu.org/lh/man-db/trunk/revision/1070?compare_revid=1067

What's happening here is twofold, but it stems from a single bug. When doing exact-section database lookups, man-db was incorrectly returning all results for which the section found in the database is a prefix of that which was requested. In other words, when looking for exactly acosh(3p), it was returning acosh(3) as well. This sounds fairly minor, but there are two consequences of this:

1) When mandb processes acosh(3p), it does an exact-section database lookup to check whether it's already seen it. This returns acosh(3) which it just processed earlier and it decides it doesn't need to do any more. Then it processes acoshl(3p), which causes it to insert an entry for that, but also causes it to insert a ghostly "whatis" entry for acosh(3p), which are mostly there to attempt to support people writing extra names into the NAME section of manual pages but not installing links on the filesystem as they should. Normally this whatis entry would be discarded because there would already be a real-page entry which takes precedence, but that didn't happen for the reason just given, so the database ends up storing: acosh(3) real page, acosh(3p) whatis, acoshl(3p) link.

2) When mandb is run a second time, it looks for any modified directories, and has a quick look through them to see if anything changed. One of the things it checks is whether any of those ghostly whatis entries appear to have turned into real pages, which normally means that it needs to scan that page to update its records. In this case, it looks up acosh(3p) with another one of those exact-section database lookups, which as mentioned are not very reliable, although in this case it sort of gets lucky because there is a real acosh(3p) there now. But - oh dear, it's a whatis entry, and yet there's an acosh.3p.gz file on the filesystem. Better rescan to see what it contains ...

As far as I can tell, my patch fixes this. Please let me know if there's still a problem of this nature after Andreas or one of the other Arch developers applies it. Thanks for your report and the debugging information, and sorry I took a while to deal with it!

I just applied that patch and built this locally (had to remove the Changelog hunk though) - running mandb twice made the second run take only a second or so:

0 man subdirectories contained newer manual pages.
0 manual pages were added.
0 stray cats were added.
0 old database entries were purged.

EDIT: I took the liberty of putting an updated package to testing.

looks solved also on my system. Thanks Colin.

Allan, can you give more details about why you reopened this?

As I said in a previous comment: for problems like this, please run mandb with --debug (and without --quiet) and attach the output.

There appears to be a regression with the latest 2.5.6-1 update.
Mandb does build the full database again every time it has been called.
See this forum thread: http://bbs.archlinux.org/viewtopic.php?pid=616872

Debug log attached. mandb has been called immediately after a previous mandb run.

OK. Could you now also attach the following three files:

/var/cache/man/index.db
/usr/share/man/man5/modprobe.conf.5.gz
/usr/share/man/man5/modprobe.d.5.gz

Attached.

Sorry, had to resolve permissions first.

Argh! File too big.

Thanks. This is a new cause of the same symptom, not as far as I can see a regression from the previous fix.

The proper fix in man-db is a little involved, and I'll have to think about it, but at least I have a test case now. In the meantime, your modprobe.d.5.gz is buggy anyway and ought to be fixed. I suggest that it be corrected as follows:

-.so modprobe.conf.5
+.so man5/modprobe.conf.5

(.so includes should always be relative to the *base* of the manual hierarchy, e.g. /usr/share/man in this case.) Fixing this will make this particular cause go away, although of course it's possible that there are other similar pages ...

The correction to modprobe.d.5.gz suggested by Colin fixes the issue for me. :)

Works here as well now. Thanks, Colin!

Is there anything we can do globally to fix this?

Mailed the module-init-tools project maintainer about their broken man-page and I'm going to fix it for ArchLinux now.

As Collin is aware of this bug we can close this one I think.

When we will find more broken links in man pages please open one bug per page and assign it to me + the package maintainer. Closing this one now.