更新共享库而不重新启动进程

正在运行的进程不能立即升级链接库。 你甚至可以尝试，但是如果你成功了（而且你不会失败并显示一个“正在使用的文本文件”的错误信息），你将不得不重新开始这个过程，把它映射到内存中。

您可以使用lsof命令来检查哪些库链接（运行时或链接时间）：

lsof -p <process_pid> | grep ' mem ' 

一个有趣的技术，虽然有点在检查点恢复步骤中容易失败，但是做一个不可见的重启。

您的服务器进程或任何它，将所有必要的信息保存到磁盘文件。 包括文件描述符号码和当前状态。 然后，服务器进程执行exec系统调用来执行自己，取代当前的版本。 然后它从磁盘文件中读取它的状态并恢复为其文件描述符提供服务，就像没有任何事情发生一样。

如果一切顺利，重新启动是不可见的，新进程正在使用所有更新的库。

至少，你必须确保库的接口在版本之间不会改变。 如果这是确定的，那么我会试着动态加载与dlopen / dlsym库，看看是否允许您重新加载dlclose。

我自己从来没有做过这样的事情，但这是我首先要追求的道路。 如果你这样做，你能发表结果吗？

Linux提供了几个动态加载器接口，运行时可以加载动态库。 Linux提供的dlopen和dlsysm可以解决你的问题。

ldd你的进程的二进制文件是找出的一种方法。 虽然这在理论上是可行的，但是我们不可能修改正在运行的进程，尽管我相信公用程序存在，比如ksplice可以修改正在运行的linux内核。

您可以简单地升级，运行的过程将继续使用旧版本，并在重新启动时选择新版本，假设您的软件包管理系统是好的，并且知道什么是可兼容的安装。

您可能想了解共享库版本和ld -h选项。

一种使用方法如下：

您在构建系统中维护一个版本计数器。 您使用以下方式构建共享库：

 ld ..... -h mylibrary.so.$VERSION 

不过，你把它放在你的开发树的lib，只是简单的mylibrary.so 。 （还有一个涉及将整个.so文件放入.a文件的黑客攻击）。

现在，在运行时，使用库的进程查找完全版本的名称。 要推出新版本，只需将新版本添加到图片即可。 运行与旧版本链接的程序将继续使用它。 随着程序被重新链接并针对新程序进行测试，您将推出新的可执行文件。

有时你可以升级一个正在使用的.so，有时你不能。 这主要取决于你如何去做，而且还取决于你正在运行的内核的安全性。

不要这样做：cat new.so> old.so …因为最终，你的过程可能试图要求页面的东西，并发现它不在正确的位置了。 这是一个问题，因为事物的地址可能会改变，它仍然是相同的inode; 你只是覆盖文件中的字节。

但是，如果你：mv new.so old.so你可以在大多数系统上正常运行，因为你的运行进程可以保存旧库的一个未命名的inode，而你的进程的新调用将获得新文件。 但是，有些内核不喜欢让你使用，也许出于谨慎，也许是为了自己的简单。

如果你期望libaries经常改变，而且期望保持正常运行，那么我认为你的系统应该被重新设计，以便这样的库实际上成为松耦合的组件（例如服务）。

话虽如此，我对这个问题的回答是肯定的：在某些情况下， 可以在不重新启动进程的情况下更新共享库。 在大多数情况下，我认为这是不可能的，例如当你的库的API改变，当你的数据段的安排改变时，当库维护内部线程时。 这个清单很长。

对于代码的很小的错误修复，仍然可以使用ptrace写入进程内存空间，然后从那里重做/lib/ld-linux.so在动态链接方面的功能。 老实说，这是一个非常复杂的活动。