Ubuntu – On Ubuntu Linux, is it normal for mandb to run continuously (apparently in the background)

clustercpulinuxmanUbuntu

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?

Best Answer

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).

Related Solutions

CPU Usage Stats – Monitor Core Usage with Top

When using top, press '1' and you should see the different CPUs (or VCPUS) and their load distribution. Probably top reports 80% but not all the CPUs are busy, with this option you should be able to see something else. On other hand you can try htop

linux cpu – Setting Process Affinity with Taskset Fails

Update: Newer versions of taskset have a -a/--all-tasks option that "operates on all the tasks (threads) for a given pid" and should solve the behavior I show below.

I wrote a Python script that simply spins up some threads and burns CPU cycles. The idea is to test taskset against it, as it's quite simple.

#!/usr/bin/env python

import threading

def cycle_burner():
    while True:
        meh = 84908230489 % 323422

for i in range(3):
    thread = threading.Thread(target=cycle_burner)
    print "Starting a thread"
    thread.start()

Just running the Python script eats up about 150% CPU usage.

[~/cbench]$ ./burn_cycles.py
Starting a thread
Starting a thread
Starting a thread

Launching my Python script with taskset works as expected. Watching top shows the Python process pegged at 100% usage.

[~/cbench]$ taskset -c 0 ./burn_cycles.py
Starting a thread
Starting a thread
Starting a thread

Interestingly, launching the Python script and then immediately using taskset to set the just-started process' affinity caps the process at 100%. Note from the output that the Linux scheduler finished executing the Bash commands before spawning the Python threads. So, the Python process was started, then it was set to run on CPU 0, then it spawned its threads, which inherited the proper affinity.

[~/cbench]$ ./burn_cycles.py &; taskset -pc 0 `pgrep python`
[1] 8561
pid 8561's current affinity list: 0-3
pid 8561's new affinity list: 0
Starting a thread
[~/cbench]$ Starting a thread
Starting a thread

That result contrasts with this method, which is exactly the same but allows the Python threads to spawn before setting the affinity of the Python process. This replicates the "taskset does nothing" results I described above.

[~/cbench]$ ./burn_cycles.py &
[1] 8996
[~/cbench]$ Starting a thread
Starting a thread
Starting a thread
[~/cbench]$ taskset -pc 0 `pgrep python`
pid 8996's current affinity list: 0-3
pid 8996's new affinity list: 0

What's going wrong here?

Apparently threads spawned before the parent process' affinity is changed don't inherit the affinity of their parent. If someone could edit in a link to documentation that explains this, that would be helpful.

Best Answer

Related Solutions

CPU Usage Stats – Monitor Core Usage with Top

linux cpu – Setting Process Affinity with Taskset Fails

Related Question