blocks|key|1793566|text|也许对某人有帮助:我经常在我们的CI上碰到这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1793567|只需执行以下操作：|1793568|sudo+apt-get+remove+-y+--purge+man-db|code-block|syntax|javascript|1793569|该命令完全删除了man-db包，在我们的CI中，这个包无论如何都是完全无用的。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|N|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|O|8|@]|9|@]|A|$]]]|K|$]]

Might be helpful for someone: I ran into this issue on our CI regularly.

Just execute the following:

<pre><code>sudo apt-get remove -y --purge man-db
</code></pre>

The command removes the man-db package completely, which in our case on CI, was completely useless anyway.

blocks|key|1793633|text|可能mandb索引已损坏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1793634|检查索引并重新创建它|1793635|sudo+mandb+-t
rm+-rf+/var/cache/man
sudo+mandb+-c|code-block|syntax|javascript|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|L|8|@]|9|@]|A|$G|H]]]|I|$]]

It's possible the mandb index is corrupted.

check the index and recreate it 

<pre><code>sudo mandb -t
rm -rf /var/cache/man
sudo mandb -c
</code></pre>

blocks|key|1793737|text|只有当文件Processing+triggers+for+man-db存在时才执行/var/lib/man-db/auto-update步骤。这是一个空文件，唯一的目的是控制这种行为，因此可以安全地删除它，以禁用这个耗时且可以说是不必要的过程。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1793738|我个人在我所有的系统上都禁用了这个触发器。虽然manual缓存应该能提高手动页面系统的速度和功能，但在禁用触发器之后，我没有遇到任何明显的性能下降或功能问题。|entityMap^0|5|U|15|R|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]|$9|L|A|M|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|N|8|@]|D|@]|E|$]]]|H|$]]

The <code>Processing triggers for man-db</code> step is only executed if the file <code>/var/lib/man-db/auto-update</code> exists. This is an empty file with the sole purpose of controlling this behavior, so it can be safely removed to disable this time-consuming and arguably unnecessary process.
I personally disable this trigger on all of my systems. While the man-db cache is supposed to enhance the manual page system's speed and functionality, I have not experienced any noticeable performance degradation or functional problem after disabling the trigger.

blocks|key|1793538|text|在上安装Ubuntu18.04并运行update和upgrade之后，我看到了类似的情况:Ubuntu18.04被processing+triggers+for+man-db+(2.8.3-2)卡住了。之后，在运行之后|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1793539|sudo+apt+install+python3-pip|code-block|syntax|javascript|1793540|我的解决方案:我只是在等。在第二种情况下，甚至大约15分钟。我不知道这是否正常，因为我对Linux非常陌生。但这样，如果遇到同样的问题，人们就会知道另一种经历。|entityMap^0|I|6|P|7|1L|14|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|U|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|V|8|@]|D|@]|E|$]]]|M|$]]

I had something similar just after installing Ubuntu 18.04 on Windows Subsystem for Linux and running <code>update</code> and <code>upgrade</code>: it got stuck at <code>processing triggers for man-db (2.8.3-2)</code>.
And also later, after running

<pre><code>sudo apt install python3-pip
</code></pre>

My solution: I just waited. In the second case even some 15 minutes.
I do not know whether this is normal, as I am very new to Linux. But this so people just know another experience if they run into the same problem.

blocks|key|1793595|text|当我在我的数字水滴上安装apache服务器时，我也遇到了同样的问题。等了一会儿后，我只需停止进程并重新运行命令。它显示apache已经安装并正常工作。我希望这还能帮上忙。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

I have had the same problem when I was installing apache web server on my digital ocean droplet. After waited a bit, I simply just stop the process and rerun the command. It shows the apache is already installed and it worked. 
I hope it can still help.

blocks|key|1793651|text|Processing+triggers+for+man-db是I/O绑定的，如果您使用HDD或Google的默认磁盘存储层，则会非常慢。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1793652|升级磁盘|entityMap^0|0|U|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|L|8|@]|D|@]|E|$]]]|H|$]]

<code>Processing triggers for man-db</code> is I/O bound, and can be painfully slow if you are on a HDD, or Google Cloud's default disk storage tier.
Upgrade your disk

blocks|key|1793712|text|因为我有时需要手册。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1793713|而且，由于似乎没有独立的“man”包，所以我不能简单地删除“man”。|1793714|我的解决方案，无论是好是坏，都是将“mandb”可执行文件移开，并替换为“true”的副本。|1793715|在我的系统里：|1793716|sudo+mv+/usr/bin/mandb+/usr/bin/mandb-OFF
sudo+cp+-p+/bin/true+/usr/bin/mandb+
sudo+rm+-r+/var/cache/man|code-block|syntax|javascript|1793717|如果需要的话，这很容易撤销。我删除了/var/cach/man目录，因为它不再需要并恢复了兆字节的空间。|1793718|您需要的任何“手册”页都会从源man目录中抓取并动态解压缩。不再缓存意味着效率有点低，但是对于当今的高速处理器和磁盘来说，它是最小的。|1793719|警告:无论何时，只要您得到一个man包更新，您的修改都将被覆盖。要么持有‘man’包，要么准备随心所欲地重做‘man’包维护人员和分发管理器。|1793720|在这个模块之后，您仍然会看到一行“man的处理触发器”飞逝而过，但这是一件零秒的事情。:-)|1793721|祝好运。|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|11|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|13|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|14|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|15|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|16|8|@]|9|@]|A|$]]]|W|$]]

Since I sometimes need the man pages.
And since there doesn't seem to be a stand-alone 'man' package, I can't simply remove 'man-db'.
My solution, for better or worse, was to move the 'mandb' executable out of the way and substitute in a copy of 'true'
On my system:
<pre><code>sudo mv /usr/bin/mandb /usr/bin/mandb-OFF
sudo cp -p /bin/true /usr/bin/mandb 
sudo rm -r /var/cache/man
</code></pre>
This is easy to undo if the need arises. And I deleted the /var/cach/man directory, as it is no longer needed and recovered megabytes of space.
Any 'man' pages you need are grabbed from the source man directory and decompressed on the fly. No more caching means a slight inefficiency, but with today's speeder processors and disks, its minimal.
A caveat: Anytime you get a man-db package update, your modifications will be overwritten. Either apt-hold the 'man-db' package or be prepared to redo this at the whim of the 'man-db' package maintainers and distribution managers.
After this mod, you will still see the line &quot;Processing triggers for man-db&quot; fly by but it's a zero second thing. :-)
Good Luck.

When running sudo aptitude upgrade, the console freezes for long after almost every package upgrade with a message "Processing triggers for man-db ...". What could be the problem and how can I fix it?

Ubuntu version: 12.04 (both Server and Xubuntu)

Thanks in advance.

<hr>

Update: It looks like this problem is related to package autofs upon my further tests. Removing autofs resolved the issues. No idea why. I then have to use soft links instead of autofs for my file system to avoid this issue (and other two issues posted here as well).

Processing triggers for man-db

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

当运行sudo智能升级时，控制台在几乎每个包升级之后都会冻结很长时间，其中包含一条消息“man.的处理触发器”。问题可能是什么，我该如何解决？Ubuntu版本: 12.04 (服务器和Xubuntu)提前谢谢。更新:在我的进一步测试中，这个问题似乎与package有关。删除autofs解决了这些问题。不知道为什么。然后，我不得不为我的文件系统使用软链接而不是autofs，以避免这个问题(以及这里发

问man-db的处理触发器
EN

回答 7

Ask Ubuntu用户

Ask Ubuntu用户

Ask Ubuntu用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问man-db的处理触发器EN

回答 7

Ask Ubuntu用户

Ask Ubuntu用户

Ask Ubuntu用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问man-db的处理触发器
EN