为什么更新正在运行的 Linux 系统没有问题?

25 executable software-installation upgrade

多年来,我每天都使用 Linux 系统,并且在系统运行时更新系统从来没有遇到过重大问题,但我仍然想知道为什么这是可能的。

让我举个例子。

假设来自某个包的程序“A”正在系统上运行。该程序在某个时刻需要从同一个包中打开另一个文件(“B”)。之后,程序“A”关闭“B”,因为它不再需要它。假设现在我更新了“A”和“B”所属的包。“A”不受此操作的直接影响,至少目前是这样,因为它在 RAM 中运行并且更新刚刚替换了硬盘上的“A”。假设文件系统上的“B”也被替换了。现在“A”出于某种原因需要再次读取“B”。问题是:“A”是否有可能找到与“B”不兼容的版本并以其他方式崩溃或故障?

为什么没有人通过使用 Live CD 或类似程序重新启动来更新他们的系统?

Cod*_*ome 23

更新用户空间很少成为问题

您通常可以在实时系统上更新软件包,因为:

  1. 共享库存储在内存中,而不是在每次调用时从磁盘读取,因此旧版本将继续使用,直到应用程序重新启动。
  2. 打开的文件实际上是从file-descriptors读取的,而不是文件名,因此即使在移动/重命名/删除时,文件内容仍然可供正在运行的应用程序使用,直到扇区被覆盖或文件描述符关闭。
  3. 如果包设计良好,需要重新加载或重新启动的包通常由包管理器正确处理。例如,每当 libc6 升级时,Debian 都会重新启动某些服务。

通常,除非您正在更新内核并且未使用 ksplice,否则可能需要重新启动程序或服务才能利用更新。然而,很少需要重新启动系统来更新用户空间中的任何内容,尽管在台式机上有时比重新启动单个服务更容易。

也可以看看

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode

  • 实际上#1的描述不是那么清楚。旧的库文件内容保留在一个单独的(原始)inode 下,即使链接到它的所有名称都消失了,只要某个进程打开了文件,或者映射了它的内容,数据就会保持不同(并且文件系统不能重新挂载 r/o 直到文件的取消链接完成)。映射原始文件的进程仍然具有到原始内容的内存映射。 (3认同)