如果我的进程正在加载一个 .so 库，并且如果有新版本的库可用，是否可以在不重启进程的情况下切换到新库？或者答案取决于库中现有函数之一是否有参数更改？
我在一个相当大的系统中工作，该系统运行 100 个进程，每个进程加载 10 个库。这些库提供特定的功能，由不同的团队提供。因此，当库中的一个更改（可以说是错误修复）时，理想的做法是在不影响运行过程的情况下在后台发布它。有可能吗？
编辑谢谢！在我的情况下，当一个新库可用时，所有正在运行的进程都必须开始使用它。让他们使用旧版本运行并稍后再选择新版本是不可取的。所以看起来更安全的选择是重新加载进程。
【问题讨论】：
标签： c linux dll shared-libraries
您无法在进程运行的情况下即时升级链接库。 你甚至可以尝试，但如果你成功了（并且你不会因为“文本文件正在使用”错误消息而失败），你将不得不重新启动该过程以使其将新库映射到内存中。
您可以使用 lsof 命令检查哪些库被链接（运行时或链接时）：
lsof -p <process_pid> | grep ' mem '
【讨论】：
lsof -p <pid>，你也可以使用pldd <pid>。
dlopen/dlclose 的存在是为了能够通过动态链接的库实现这一目标。
一种有趣的技术，虽然它在检查点恢复步骤中有点容易失败，但它是进行不可见的重启。
您的服务器进程或任何其他进程都将其所有必要信息保存到磁盘文件中。包括文件描述符编号和当前状态。然后，服务器进程执行exec 系统调用来执行自身，替换自身的当前版本。然后它从磁盘文件中读取它的状态并继续提供它的文件描述符，就像什么都没发生一样。
如果一切顺利，重启是不可见的，新进程正在使用所有更新的库。
【讨论】：
至少，您必须确保库的接口不会在版本之间发生变化。如果可以确定，那么我会尝试使用 dlopen/dlsym 动态加载库，看看 dlclose 是否允许您重新加载。
我自己从来没有做过这些，但这是我首先要追求的道路。如果你这样走，你能公布结果吗？
【讨论】：
Linux 提供了几个动态加载器接口，进程可以在运行时加载动态库。 linux提供的dlopen和dlsysm或许能解决你的问题。
【讨论】：
如果您希望库会定期更改，并且 您希望保持正常运行时间，我认为您的系统 应该重新设计，以便这些库实际上成为 松散耦合的组件（例如服务）。
话虽如此，我对这个问题的回答是肯定的：在某些情况下 在这种情况下，可能更新共享库而不 重新启动进程。在大多数情况下，我认为这是不可能的， 例如，当您的库的 API 更改时，当 当库发生变化时，您的数据段的排列 维护内部线程。清单很长。
对于代码的非常小的错误修复，您仍然可以使用 ptrace 写入进程内存空间，并从 重做/lib/ld-linux.so 在动态方面所做的事情 链接。老实说，这是一项极其复杂的活动。
【讨论】：
ldd 进程的二进制文件是找出问题的一种方法。尽管理论上可行，但不建议修改正在运行的进程，尽管我确信存在一些实用程序，例如 ksplice 可以修改正在运行的 linux 内核。
您可以简单地升级，运行过程将继续使用旧版本，并在重新启动时选择新版本，假设您的包管理系统良好并且知道可以安装什么。
【讨论】：
您可能想了解共享库版本控制和 ld -h 选项。
一种使用方式如下：
您在构建系统中维护一个版本计数器。您使用以下方式构建共享库：
ld ..... -h mylibrary.so.$VERSION
然而，你把它放在你的开发树的库中，就像普通的mylibrary.so。 （还有一个 hack 涉及将整个 .so 放入一个 .a 文件）。
现在，在运行时，使用该库的进程会查找完整版本的名称。要推出新版本，您只需将新版本添加到图片中。运行与旧版本链接的程序继续使用它。随着程序重新链接并针对新程序进行测试，您推出了新的可执行文件。
【讨论】：
有时您可以升级正在使用的 .so，有时则不能。这主要取决于您如何尝试执行此操作，还取决于您运行的内核的安全保证。
不要这样做： 猫 new.so > old.so ...因为最终，您的进程可能会尝试要求页面某些内容，并发现它不再位于正确的位置。这是一个问题，因为东西的地址可能会改变，它仍然是同一个inode；你只是覆盖了文件中的字节。
但是，如果您： mv new.so old.so 在大多数系统上你会没事的，因为你正在运行的进程可以为旧库保留一个现在未命名的 inode，而对你的进程的新调用会得到新文件。 但是，有些内核不喜欢让你 mv 一个正在使用的 .so，也许是出于谨慎，也许是为了它们自己的简单性。
【讨论】：