man-db takes a long time to complete tasks and issues warnings and other messages

For some days I have been observing the strange phenomenon that once a day when the PC starts up for the first time, apparently this "daily job" mandb --quiet takes far too long to complete this process. I have spent some time reading and the experts agree that this process can only take a few seconds, otherwise there is a mistake.

In my Gnome system (latest RC-ISO with latest updates), this process takes between 4 to 5 minutes! Due to the good support here in the forum, I was able to narrow down the error and have removed the (for my system) erroneous entry "discard" from the file fstab. As a result, the load has improved somewhat, but the overall duration of the mandb --quiet process has not improved.

Now I ran the mandb -c command and after a few minutes received the error message:
mandb: Warnung: /usr/share/man/man3/pcredemo.3.gz: whatis-Verarbeitung für pcredemo(3) fehlgeschlagen

Can someone kindly confirm this behavior or has a solution?

Got the same behavior here on Xfce. Last time this morning the process took around 5 minutes using ca. 25% of all the 4 CPU cores.

1 Like

There are always new surprises.

After executing the "mandb -c" command yesterday to have the entire index rebuilt, this process is terminated after a long time with an error message. I had already reported that yesterday.

After I started my PC today, I realized that the process "mandb --quiet" was not executed anymore.

@Marte
I am quite sure that we are not the only ones with this problem, at least with the "mandb" matter. Yesterday I reported my finding in the area of ​​"Testing Updates" and even mentioned @philm , but then @AgentS spoke up and told me that my content did not seem to belong at this point.

Just ran mandb -c here on a slow VM, a few warning messages but everything was fine, it ran through.

So I think we need more info.
Can you check your logs?

Which one?
A fatal one?
mandb: Warnung: /usr/share/man/man3/pcredemo.3.gz: whatis-Verarbeitung für pcredemo(3) fehlgeschlagen**
That's not en error, but a warning.

1 Like

The word "fehlgeschlagen" has for me the meaning of an error. But well, if all that is not so important, then everything seems ok. However, I can not understand that the process takes so much time. Also, I am surprised that this process is not repeated (daily job mandb --quiet) when I restart the PC before the job is over.

Is it ok if this "daily job mandb --quiet" does not run once a day? Currently it's the same with me as reported above.

Yeah, but the word "Warnung" has for me the meaning of a warning :slight_smile:

It's not the indexation of manpages that fails, but just a "subprocess", namely whatis, on a specific manpage, namely pcredemo.

whatis is a command that prints a one-line summary of what a specific command is, e.g:

$ whatis bash
bash (1)             - GNU Bourne-Again SHell

If you run whatis on pcredemo, you will probably get nothing, but the manpage still works.

1 Like

And you are correct - the process that reads that file is "fehlgeschlagen".

But it is not an error the makes the entire application break - it is an error in the sense the requested file could not be processed as expected.

2 Likes

Thank you all for the nice feedback and the good explanations. Now I understand the context much better. :slightly_smiling_face:

I'm also experiencing the same problem sometimes right after login. In the meantime, what I'm doing is stopping the mandb process from System Monitor. Since I'm not a very technical user, I wanna ask if I'm causing any risk or damage by doing so.

Thank you for your feedback signal! :wink:

I had asked about 5 days ago in my post from this conversation, if it is problematic to generally disable this process. So far, however, no one has commented. That's not bad, because I'm going to get myself into the matter because I want to know what I'm doing, and why. So an answer would be useful for the moment, but the expertise is better.

Finally, I was very surprised when I reinstalled my system a few days ago and then immediately shut down the PC and started it again the next day. In this rest period of the PC, nothing was done, so that I thought it was very strange that man-db has so much to do. That was the reason why I registered here in the forum.

If you don't want man-db to run, disable or mask the timer (man-db.timer).
You can still manually update the database in case you want to read the newest manpages.
Or copy the timer file over to /etc/systemd/system, and set it to run on a weekly basis instead.
By the way, the man-db service uses lowest possible priority so at least in theory it shouldn't get too much in the way of other tasks in terms of I/O.

4 Likes

I ran mandb -c as mentioned in this thread just to see what happens, what I got was this:

0 man subdirectories contained newer manual pages.
0 manual pages were added.
0 stray cats were added.
No databases created.

I have absolutely no idea if this is a good thing or a bad thing. Or maybe it turned out like that because I stopped the process again after it spiked my cpu usage when I logged in earlier. Honestly, I was expecting to get the usage spike that I would've needed to stop again. :smile:

Use it with sudo "sudo mandb -c" -> then your result will look different. :wink:

But this has nothing to do with the comments of @anon23612428 2 hours ago. :frog:

Processing manual pages under /usr/share/man...
Updating index cache for path `/usr/share/man/man7'. Wait...mandb: warning: /usr/share/man/man7/parallel_book.7.gz: whatis parse for parallel_book(7) failed
mandb: warning: /usr/share/man/man7/parallel_design.7.gz: whatis parse for parallel_design(7) failed
mandb: warning: /usr/share/man/man7/parallel_tutorial.7.gz: whatis parse for parallel_tutorial(7) failed
Updating index cache for path `/usr/share/man/man3'. Wait...mandb: warning: /usr/share/man/man3/pcredemo.3.gz: whatis parse for pcredemo(3) failed
mandb: warning: /usr/share/man/man3/pcre2demo.3.gz: whatis parse for pcre2demo(3) failed

Okay, so this is what I got now with sudo. I hit ctrl+c before it could finish by itself. I originally made a post on this in the October stable update thread because I thought it was brought on by that update (maybe it is?). In any case, I never encountered this problem on the September update.

1 Like

Yes, that's exactly how I did it.

But @anon23612428 has shown us all good opportunities to change this phenomenon accordingly. Some had also reported about the apparently unusually high CPU load for this process. Anyway, now we have the possible solutions of @anon23612428. :yum:

I'm not really comfortable disabling system defaults especially if it is a background process that I do not fully understand, although based on your post, I think the process has something to do with manpages (which I've never used).
Is the nature of the problem due to something that "broke" or changed in between the September stable update and the October stable update? Because if that's the case, I think I'd rather keep manually stopping the process such that if it happens to get fixed in a future update, I don't risk forgetting to re-enable it again.
Or is the problem by any chance a normal, expected system behavior such that if I let it complete, it won't eat too much cpu cycles next time? In this case, I think the correct solution for me would be to find a convenient time to let it do its thing so I won't have to worry about it again.
Currently, I really have no idea what causes the problem and what side effects the possible solutions can bring, so I can't tell which solutions I should go with.

@Cataforte
You're probably waiting for the answer from torvic9. I would like to report on my current status.

I've been working on pacman and systemd, very interesting, and I'm currently on Arch (Arch itself). I have now worked out the optimal and at the same time final variant for me. If you also want to have peace and quiet for good:

sudo systemctl mask man-db.service
sudo systemctl mask man-db.timer
sudo pacman -Rscu man-db

I've been using my system for some time after this change, updating core components and installing some additional applications. There was no time any hints or error messages that man-db misses. But ultimately, everyone should decide for themselves. I have now fulfilled my mission due to some hints from this forum and from other corners.

Here is the output of systemd-analyze time
It is not completely representative of the complete process but gives a good feedback:

startup finished in 1.818s (kernel) + 4.807s (userspace) = 6.625s 
graphical.target reached after 1.593s in userspace

The problem seems to be gone now. I ran sudo mandb -c once before I had to go afk, but within 24 hours, the new stable updates also became available and I updated my system. If I actually solved it, I don't know whether it was because I let the task finish or because the new update fixed it.

That sounds good!

However, I must confess that I have gone a bit too far with my method. Under normal circumstances, it is sufficient to use only a single command to stop the process of daily man-db regeneration.

Just use this command:

sudo systemctl mask man-db.timer

This does not start the process (daily man-db regeneration), but otherwise nothing is changed to man-db itself.

Yes, but it may have been a coincidence. If you run the command sudo systemctl status man-db.timer and then see when the timer is next executed, it may well be that there has been an overlap by manually starting the process and thus the execution of the timer has stopped, what gave you the impression that the automatic process is no longer running.

Forum kindly sponsored by