LD_LIBRARY_PATH副作用

Question

我在改变 LD_LIBRARY_PATH 时遇到了奇怪的副作用。

当我添加一个包含库的路径时，比如：

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_path/lib

然后，一切都变得难以置信的慢。例如，一个简单的ls可能需要10秒钟才能完成。

在LD_LIBRARY_PATH更改之前和之后，ldd输出完全相同，并且我尝试使用strace调试缓慢的ls的执行：在两种情况下，我得到了完全相同的执行结果。执行甚至没有在ls的执行过程中卡住（因为strace在10秒的延迟期间不输出任何内容，然后突然完美地执行ls）。所以我认为问题可能出现在我的shell中，但是这也是一样的，在我的bash上运行strace并在两种情况下执行ls会给我相同的strace输出：shell执行ls并等待其执行结束（延迟strace之前的最后一个strace输出是waitpid(...)）。所以我猜测在启动ls和它的执行之间发生了一些错误，就像是内核级别的问题。它的表现就像在ls上进行了sleep一样（0 CPU使用率）。

在延迟期间，我的CPU和网络活动都非常正常...

请注意，新的LD路径中的库不会与任何“标准库”冲突，因此它不会干扰我的示例中的ls。

因此，我对LD_LIBRARY_PATH的副作用或如何深入调试我的示例感兴趣。

- Julio Guerra

---

好问题。我使用过 LD_LIBRARY_PATH，但从未看到过这样的行为，然而你的观察似乎既孤立又明确。有趣。 - thb

export LD_DEBUG=all 是一个命令，用于设置环境变量LD_DEBUG的值为'all'，以便在运行程序时输出调试信息。man 8 ld.so 是一个命令，用于查看ld.so（动态链接器）的手册页面，包括它的用法和选项等信息。 - William Pursell

我发现导致延迟的原因，但不明白为什么（感谢 LD_DEBUG=all）：有一条路径在 LD_LIBRARY_PATH 中不存在，这条路径在一个远程服务器上... 但是同一个服务器上的其他路径绝对没有任何问题... - Julio Guerra

你在问题中写道：“我附加了一个包含库的路径”，并在评论中提到：“有一个不存在的路径”；你是指最后的LD_LIBRARY_PATH中的同一路径吗？如果不是，那么在你附加“：/my_path/lib”之前，不存在的路径是否已经存在于LD_LIBRARY_PATH中，并且当时没有引起问题？ - Armali

如果变量中的另一个路径导致了延迟，那么在修改LD_LIBRARY_PATH之前，这种情况不应该已经显而易见了吗？ - Dermot Canniffe

Answer 1

这篇文章有些年头了，所以我不知道你是否已经找到解决方案。无论如何，我不知道这是否有帮助，但在大多数现代GNU/Linux系统中，使用LD_LIBRARY_PATH已被弃用并且不鼓励使用。

因此，我有几个建议：

1. 如果您想继续使用它，请尝试将库路径添加到LD_LIBRARY_PATH的前面而不是后面。如果先前的库目录中有需要长时间扫描的内容，则应该有所帮助。

2. 使用LDCONFIG系统，这是现在使用LD目录的正确方式。您只需将库的路径添加到/etc/ld.so.conf文件中，或者更好地，在/etc/ld.so.conf.d/中添加一个包含库路径的文件（如果在/etc/ld.so.conf中有include指令，则会被引用，默认情况下通常是这种情况）。然后运行sudo ldconfig来更新系统LD搜索路径。

希望这有所帮助。干杯

- Danduk82

Answer 2

我不确定你的LD_LIBRARY_PATH上还有什么其他库，或者你正在尝试添加哪个程序，但是你最好编写一个包装脚本，仅为需要额外库的程序更改LD_LIBRARY_PATH，以便你的系统功能（如ls）不受影响。

#!/bin/bash
export LD_LIBRARY_PATH=/my_path/lib
program_name

创建文件并执行 chmod +x wrapper_name。

- k107