我应该多久重启一次Linux服务器？

我有许多用于运行Web服务的Linux服务器（SUSE 9＆10），这些服务向大型计算网格提供数据。最近，我们遇到了一些难以解释的故障（即，硬件和软件日志未显示任何明显的错误），并且我们开始怀疑是否需要长时间的正常运行时间（通常为200-300天）。鉴于这些服务器已被大量利用，我是否应该考虑定期重新启动周期？

您必须在内核更新后重新启动（除非您正在使用KSplice），否则其他任何操作都是可选的。我个人在维护时段内每月一次重新启动，以确保服务器和所有服务都能按预期返回。这样，我可以确定是否必须执行计划外的重新引导（即关键内核更新），以使系统正确恢复。对服务器和服务（即Nagios）的自动监视对帮助完成此过程也有很长的路要走（重新启动，观察指示灯变红，然后希望全部变回绿色）。

PS，如果您定期重新启动，则需要确保调整fsck检查（即，适当地检查之间的最大安装次数），否则，如果服务器开始fsck加载数TB的数据，则2分钟的快速重新启动可能需要30分钟。我通常将安装计数设置为0（tune2fs -c 0），两次检查之间的间隔设置为6个月左右，然后不时地手动强制一次fsck并重置计数。

实际上，无论何时进行重大配置更改，我都会定期重启服务器。重要的是要知道，在紧急情况下，服务器软件将毫无麻烦地出现。您需要做的最后一件事是，要设法从中断中恢复，但又必须弄乱服务器配置，因为在设置时没有对它进行彻底的测试。

除非您绝对需要更改正在运行的内核版本，否则无需重启Linux服务器。通过更改配置文件并使用初始化脚本重新启动服务，可以解决大多数问题。

您需要当心重新启动...如果您在运行中更改了任何内容而未在服务的配置文件中反映出更改，则重新启动后将不会应用这些更改。

我通常在计划的系统更新后重新启动。通常没有必要，但是当没人在办公室时我就去做，那为什么不呢？无论如何，当我要进行更新时，通常会进行内核升级。

并不是真正需要的，Linux内存处理非常出色。但是，如果您的正常运行时间如此长，则可能正在运行已知漏洞的内核-您可能要注意一下。

我认为如果最近有内核更新或libc更新，您应该重新启动。很多东西都与libc相关联，除非您重新启动，否则实际上不可能从内存中完全卸载该lib并将其替换为新版本。

例如，甚至像/ bin / ls之类的基本事物，以及/ bin中的其他事物也使用libc。如果您只是在运行控制台并使用bash，那么您正在使用libc。

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

是的，如果您更改/etc/init.d中的文件以某种方式影响启动，我建议重新启动。当您需要快速启动并再次运行时，您不想发现自己在启动文件中犯了一个小错误。

如果服务器已经运行了许多天而没有重新启动，则实际上意味着无法确保它将再次正常启动。同样，这是因为可能已更改了许多配置文件，并且很长时间没有人重新启动它以确保它启动。另外，如果服务器有大量更新，并且您很长一段时间没有重新引导，请在应用更新之前重新引导，否则，如果存在问题，则不能确定它是由配置错误引起的。很久以前还是您应用的新更新。

最后，如果您在很长一段时间后重新启动关键服务器，则fsck可能意味着您现在必须等待很长时间才能恢复。您可以使用tune2fs避免这种情况，但是我想定期检查它是一个好主意。这就是为什么您不应该仅依赖一台服务器的情况，如果这样，那么整个网站都将消失。您应该有另一个待命。

在发生意外停机时要寻找的另一件事是，查看内存和处理器的使用情况以及程序的使用方式。 top应该能够确定哪些过程是造成资源损失的罪魁祸首，然后能够直接对其进行管理。另一个想法是初始化一个cronjob，以按照特定的时间表关闭并重新启动您的进程。

如果重启的时间这么长，那么重新启动并不是一个坏主意，这样您就可以在根分区上运行磁盘检查（fsck）。您的观点可能是这有助于确保数据完整性。

正常运行的Linux服务器只需要重新启动即可进行内核更新。对于某些软件，有时不能总是这么说-例如，有时我必须重新启动apache2或mailman。

我的基础架构有两个数据站点，一个是alpha（每天进行操作），另一个是beta（备份站点，以防在alpha上出现严重错误）。尽管目前还不是这种情况，但我正在努力安排每6个月在alpha站点安排一次停机，以便我们可以从beta运行所有服务。

这将完成两件事。首先，它将证明我们的灾难恢复站点是完全可行的。其次，这将使我有一个星期的时间来消除累积的alpha残差。

实际上，我没有像应该那样频繁地重启服务器。我同意其他张贴者的意见，他们说，重要的是要知道您的服务器将在需要时重新启动。您不想“想”他们会的，只是发现您已更改某些内容而未正确执行或未对其进行记录。

您还可以编写一些脚本，这些脚本将（尽可能多地）检查计算机的当前状态是否为计算机重启后的状态。

我的意思是...

• /etc/init.d/*
  • 检查当前正在运行的所有服务是否标记为在启动时启动
  • 检查所有未运行的服务是否标记为在启动时不启动
• /etc/fstab
  • 检查所有已挂载的文件系统（例如/etc/mtab）是否在其中具有相应的条目/etc/fstab
  • 检查所有指定要在引导中挂载的文件系统/etc/fstab当前是否也已挂载。

无论如何，这当然不是一个完整的检查，但是它确实降低了重新引导后出现故障的风险。

除此之外，您应该（imo）以合理的顺序设置服务器软件包更新的策略，例如每周1组...

• 崩溃和刻录服务器
• 开发服务器，培训服务器
• 测试服务器
• 量产服务器
• 生产服务器

也要有一个总体计划，例如“所有服务器每6个月进行一次完整的操作系统升级”。

取决于服务器上运行的任务。对于某些虚拟服务器，我们经常使用重新启动而不是apachectl重新启动，它只需要5-10秒的时间。但是，一些重负载的机器每年需要重新启动几次，整个管理人员都在监视该过程。