I have access to a Ubuntu Linux node at my institution. The nodes are shared among the group, but typically I am the only person who uses this particular node.

I am running a calculation in parallel on all 8 CPUs on this node. My calculation runs, but when I view the active processes using top, I see an additional process that says user man and command mandb. This mandb command seems to be running every time I look at top, and it appears to take up a fairly appreciable amount of CPU power (6 %CPU) and memory (2.5 %MEM), according to top.

When I look around on the internet, it seems that:

mandb is used to initialise or manually update index database caches that are usually maintained by man.

Why, then, does mandb run all the time on this node? (I don't have this problem on other nodes within my institution's cluster, according to top on other nodes.) Why would mandb need to run all the time, since I am not currently looking at manuals?

Is this process likely to be a phantom process that I can safely terminate using kill?

  • @derobert I am not the sysadmin. Ok, I will ask him. Thanks.
    – Andrew
    Sep 12, 2012 at 20:27

3 Answers 3


It isn't normal for mandb to run continuously. It is typical to run mandb once a day in a cron job, to perform maintenance task such as updating an index of installed man pages and building or trimming a cache of formatted man pages. The daily job should run in a few seconds, perhaps a few minutes if you have a lot of man pages and a slow disk. If the job runs for longer than that, there's something wrong.

6% CPU isn't high, but the process may be doing disk I/O. 2.5% of the memory on a cluster node sounds high. It's likely that the job is misconfigured and looking where it shouldn't be, or that there's a bug in the mandb program, or that there's a hardware failure causing mandb to become stuck.

You can watch the cron scripts in /etc/crontab or /etc/cron.*/* (the exact location is distribution-dependent; /etc/cron.daily/man-db and /etc/cron.weekly/man-db are likely locations). You can see what invoked mandb by looking at the process more closely: run pstree | less and search for the mandb process. Running ps ww 12345 (where 12345 is the PID of the offending process) will show the complete command line.

This is something that you might be able to diagnose on your own, but not fix without root permissions. If you do have root permissions, you can safely kill the mandb process (use the command sudo pkill mandb or su -c 'pkill mandb', depending on how you become root). In any case, contact your system administrator and explain the symptoms. Give all the information you can (such as what program invoked mandb and with what arguments).


I checked the cron scripts, it was merely a command to update man indices, speed up searching for manuals, runs daily, you can kill it safely.

You don't like it, just disable it by chmod -x /etc/cron.daily/man-db


This is a Heisenbug, and possibly one that has been fixed in recent versions of mandb. It has to do with broken manpages, filesystem traversal order, and incremental rebuilds of the mandb turning into very slow full rebuilds (15 million page faults or so, which takes minutes on spinning rust).

If you want to troubleshoot it, run:

sudo mandb --no-purge --debug

and don't ever run mandb with --create or without --no-purge. Then make sure you have the latest version and report a bug where cjwatson can see it.

If on the other hand you just want to get rid of the problem, run:

echo 'man-db man-db/auto-update boolean false' |sudo debconf-set-selections

which will disable the man-db cronjob (runs daily) and the dpkg trigger (runs when packages are installed).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .