我应该多久重新启动Linux服务器？

内核更新后必须重新启动（除非您使用的是KSplice），否则其他任何选项都是可选的。 就我个人而言，我在维护窗口期间按月重新启动，以确保服务器和所有服务按照预期恢复。 这样，我可以合理地确定，如果我必须做一个超时重新启动（即关键的内核更新），系统将恢复正常。 服务器和服务（例如Nagios）的自动化监控对帮助这个过程也有很长的路要走（重新启动，看着灯变红，然后希望所有灯都变回绿色）。

PS如果你经常重新启动，你会希望确保你调整你的fsck检查（即两次检查之间的最大安装次数是否合适，否则如果服务器启动了几TB的数据，那么快速的2分钟重新启动可能需要30分钟。我通常将我的安装计数设置为0（tune2fs -c 0），并将检查之间的时间间隔设置为6个月左右，然后每隔一段时间手动强制一次fsck并重置计数。

实际上，我经常重新启动服务器，任何时候都会进行重大configuration更改。 重要的是要知道，在紧急情况下，服务器软件将毫无麻烦地出现。 你想要的最后一件事就是要在一个位置上试图从停机中恢复，但是由于在设置时没有对其进行全面testing，所以不得不惹恼你的服务器configuration。

除非您绝对需要更改正在运行的内核版本，否则Linux服务器永远不需要重新启动。 大多数问题可以通过更改configuration文件并使用init脚本重新启动服务来解决。

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

不过，我通常会在预定的系统更新后重新启 这通常不是必要的，但是当我没有人在办公室时，他们会这样做，为什么不呢？ 无论如何，当我进行更新时，往往会有内核升级。

不是真的需要，linux内存处理是非常好的。 但是，如果你有这个长度的正常运行时间，你可能正在运行已知漏洞的内核 – 你可能想看。

我想你应该重新启动，如果有最近的内核更新或libc更新。 很多东西都与libc链接在一起，而且完全不可能从内存中卸载这个lib，除非你重新启动，否则用新版本replace它。

例如，甚至像/ 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中影响启动的文件，我build议重新启动。 当您需要快速启动并重新运行时，您不希望发现自己在启动文件中犯了一个小错误。

如果一台服务器没有重新启动多天，它实际上意味着没有办法确定它会再次正确地出现。 再一次，这是因为很多configuration文件可能已经改变了，没有人重新启动了很长时间，以确保它出现。 另外，如果服务器有很多更新到期，并且很长一段时间没有重新启动，请在应用更新之前重新启动，否则如果出现问题，则无法确定是由configuration错误引起的很久以前还是应用了新的更新。

最后，如果你在很长一段时间后重启一台关键的服务器，fsck可能意味着你现在必须等很长时间才能恢复。 你可以使用tune2fs来避免这种情况，但是我认为最好定期检查它。 这就是为什么你不应该只处于一台服务器的位置，如果这样做，你的整个网站都不见了。 你应该有另一个待机。

在意外停机的时候要寻找的另一件事是看看内存和处理器的使用情况以及程序。 top应该能够确定哪些进程是资源损失的罪魁祸首，然后才能够直接pipe理它们。 另一个想法是初始化一个cronjob关机，并按照特定的时间表重新启动你的进程。

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

一个正常运行的Linux服务器应该只需要重新启动内核更新。 对于某些软件来说也是如此，例如，我有时必须重新启动apache2或mailman。

我的基础架构有两个数据站点，alpha（每天都在进行操作）和beta（备份站点，以防万一在alpha时出错）。 虽然目前情况并非如此，但我正在推动每6个月在阿尔法站点安排停机时间，以便我们可以从testing版运行所有服务。

这将完成两件事情。 首先，这将certificate我们的灾难恢复站点是完全可行的。 其次，它会给我一个星期的时间来消除在阿尔法积累cruft。

事实上，我不会像我应该那样频繁地重启我的服务器。 我同意其他海报谁说，重要的是要知道，你的服务器会回来，当你需要他们。 你不想“认为”他们会，只是发现你已经改变了一些东西，没有正确地做，或没有logging下来。

你还可以写一些脚本来检查（尽可能多的），如果你的机器的当前状态，将会是机器重启后的状态。

我的意思是…

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

这当然不是一个完整的检查手段，但它确实减less了重启后的麻烦。

除此之外，你应该（imo）设置一个服务器包更新的策略，以一些合理的顺序，比如说每周1个小组…

• 崩溃和刻录服务器
• 开发服务器，培训服务器
• testing服务器
• 预生产服务器
• 生产服务器

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

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