mandb issues

belbono · 2010-03-16 11:24:05

Hey everyone,

since several weeks I'm having trouble with the daily cronjob regarding mandb. Its very slow and almost blocking the system for several minutes. Think several other people are having a similar problem.

I have installed
man-db 2.5.7-1
man-pages 3.24-1

So, I already read through threads like http://bbs.archlinux.org/viewtopic.php?pid=616277 and http://bbs.archlinux.org/viewtopic.php?id=76528. Didn't helped me so far.

I checked the problem with modprobe.d.5.gz but there wasn't an incorrect link.
According to the output from mandb, there are some bad symlinks in the net-snmp package. Anyway, this bug has already been reported (http://bugs.archlinux.org/task/18605).

I'm also getting a lot of 'ignoring bogus filename' messages.

I already tried to completely remove those packages (by pacman -Rscn man-db man-pages) and reinstalled them. Didn't help.
Calling mandb results always to the following status output:

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

So apart from the problems with the net-snmp package, what can I do get rid of this 'ignoring bogus filename' warnings?
However, until this is fixed, I think I will set the cronjob to 644.

Thanks in advance
bel

Ultraman · 2010-03-16 11:58:21

man-db got an update 2 days ago, I updated yesterday.
The update includes a new cron script which is more extended than the old one. It also includes settings for niceness, the old one does not. I see you have updated to this new version of man-db, have you also replaced the old script with the new one as pacman suggests?

The new script is at the /etc/cron.daily/man-db.pacnew and the old one is in the same directory without the .pacnew extension.
Compare the scripts and spot the niceness variables in there, perhaps they can help you with your load problem.
You can remove the old script and rename the man-db.pacnew to man-db.
Check if it is still executable after doing so, it was fine over here.

Last edited by Ultraman (2010-03-16 11:59:18)

belbono · 2010-03-16 12:45:37

Thanks for your response.

I'd already replaced the old script several days ago. It changed nothing so far.
Maybe I try setting IONICE_CLASS=3, but anyway I think this wouldn't fix the actual problems regarding 'ignoring bogus filename' and incorrect symlinks.

Ultraman · 2010-03-16 14:13:39

Okay, I'm sorry but that was my only idea for the moment.
I don't know about those bogus filenames. I have not run into that issue (yet).

Daenyth · 2010-03-16 14:20:44

There have been some issues with mandb generating the whole db instead of doing an incremental update if some files are wrong. Look on the bug tracker at the closed mandb bugs and it should provide steps to find out what files are causing the problem

linfan · 2010-03-17 19:59:07

I don't know what is wrong with man-db, but I uninstalled it completely and my computer runs more smoothly. What is the use of those man pages any way? You can read them on the web, if you need them.

Peasantoid · 2010-03-17 20:00:23

linfan wrote:

I don't know what is wrong with man-db, but I uninstalled it completely and my computer runs more smoothly. What is the use of those man pages any way? You can read them on the web, if you need them.

Some people don't always have a working connection, you insensitive clod.

Peasantoid · 2010-03-17 21:28:00

As for the 'ignoring bogus filename' messages, I've found this is caused by /usr/share/man/man3x (symlink to man3). Remove that and you should be fine.

** Crap, double-posted.

Last edited by Peasantoid (2010-03-17 21:28:20)

turing · 2010-03-19 09:15:42

I had the same issue, nothing mentioned at the bugtracker worked.

So I uninstalled man-pages and man-db.
Then I deleted /etc/cron.daily/man-db*, /var/cache/man/* and /usr/share/man/*.
Installed man-pages and man-db again and ran mandb again.

Now it takes 1 second to run the command.

Gen2ly · 2010-03-19 17:32:08

I love man pages. You guys are cruel .

Mandb put man pages in a database for faster access. It's had problems in the past when I used Debian, but haven't heard of anything since then until now. As far as accessing man pages quickly, I've always like it. Don't think I'm going to change this until I find a proper fix, or I'll wait for a fix in an update.

Last edited by Gen2ly (2010-03-19 17:32:41)

Leonid.I · 2010-03-20 20:28:48

Peasantoid wrote:

As for the 'ignoring bogus filename' messages, I've found this is caused by /usr/share/man/man3x (symlink to man3). Remove that and you should be fine.
** Crap, double-posted.

I agree. This is a bug in man-pages, right? Although, in the corresponding PKGBUILD nothing creates this link... Have you filed a bug, or should I?

L.

Peasantoid · 2010-03-20 20:40:32

Leonid.I wrote:

I agree. This is a bug in man-pages, right? Although, in the corresponding PKGBUILD nothing creates this link... Have you filed a bug, or should I?
L.

I examined man-db and man-pages from ABS and neither seems to create the problematic symlink. Looks like the problem was an archaic PKGBUILD that has since been updated.

ataraxia · 2010-03-21 01:03:06

ataraxia@amaranth:~ $ pacman -Qo /usr/share/man/man3x
/usr/share/man/man3x is owned by filesystem 2010.02-4

Peasantoid · 2010-03-21 02:56:56

ataraxia: ...or that.

Does anyone know what the purpose of that symlink is?

Leonid.I · 2010-03-21 18:27:30

Peasantoid wrote:

ataraxia: ...or that.
Does anyone know what the purpose of that symlink is?

I guess, it is just book keeping:
http://en.wikipedia.org/wiki/Man_page

So, 3x means C library manual, categorized in a X window section... Although bogus filenames errors were related to 3p, such as umask.3p.gz. This means C library, POSIX specs.

What I don't understand, is why did *.3p.gz man pages end up in the man3x dir. I suppose it should have been man3p On RHEL systems there are directories, not symlinks, like man3x.

FYI, I reinstalled man-pages and the symlink did not go away -- must be a left=over from a previous version.
PS: Of course, pacman -Qo man3x/* will point to man-pages.

Peasantoid · 2010-03-21 21:57:32

Leonid.I: As ataraxia said, man3x/ is in filesystem, not man-pages. Since -x seems to be a standardized suffix, the issue would appear to lie with man-db instead.

Leonid.I · 2010-03-21 23:35:41

Oops, my bad. Sorry for that ataraxia, must have misread your post.

Actually this now makes sense, just take a look at the latest filesystem PKGBUID from ABS. Therefore, it's not man-db related. I would argue that it is a bug, since a more logical layout would be to create man3{x,p} and copy all *.3{x,p}.gz files in there, so that man3 contains only *.3.gz.

I can file a bug, if you guys agree.

L.

Peasantoid · 2010-03-22 02:11:54

What I mean is that mandb is buggy for choking on man3x, since man*x should be considered valid. Instead it calls that a 'bogus filename'.

If I have time later, I'll sift around in the source and see if I can hunt me some bugs.

** Hmm... actually I see what you mean -- it's not that mandb dislikes man*x, it's that there's a mismatch between man3x/foo.3.gz (when it should only be seeing foo.3x.gz). So yeah, bug in man-pages and/or filesystem, not man-db.

Last edited by Peasantoid (2010-03-22 02:19:20)

Leonid.I · 2010-03-22 17:00:53

Apparently, we were not the first to notice this, because there is a bug report FS#18783 agains filesystem.

goetzkluge · 2010-11-19 21:18:55

mandb run 20 minutes today. Conkey reported 3 instances running at times.

Arch Linux

#1 2010-03-16 11:24:05

mandb issues

#2 2010-03-16 11:58:21

Re: mandb issues

#3 2010-03-16 12:45:37

Re: mandb issues

#4 2010-03-16 14:13:39

Re: mandb issues

#5 2010-03-16 14:20:44

Re: mandb issues

#6 2010-03-17 19:59:07

Re: mandb issues

#7 2010-03-17 20:00:23

Re: mandb issues

#8 2010-03-17 21:28:00

Re: mandb issues

#9 2010-03-19 09:15:42

Re: mandb issues

#10 2010-03-19 17:32:08

Re: mandb issues

#11 2010-03-20 20:28:48

Re: mandb issues

#12 2010-03-20 20:40:32

Re: mandb issues

#13 2010-03-21 01:03:06

Re: mandb issues

#14 2010-03-21 02:56:56

Re: mandb issues

#15 2010-03-21 18:27:30

Re: mandb issues

#16 2010-03-21 21:57:32

Re: mandb issues

#17 2010-03-21 23:35:41

Re: mandb issues

#18 2010-03-22 02:11:54

Re: mandb issues

#19 2010-03-22 17:00:53

Re: mandb issues

#20 2010-11-19 21:18:55

Re: mandb issues

Board footer