在我写这篇文章时，三月底正在快速临近。在 SSC 这里，三月总是令人兴奋的时刻，因为这是一年会计年度的结束。在过去的两个星期里，Gena Shurtleff 和我（在其他人的帮助下）一直在为下一年的 LJ 制定预算——这让我们中的一些人非常暴躁。[主要是我们的出版商——编者注。]

为了使这个过程更有趣，发生了很多与计算机相关的问题——都与我们的 Linux 系统有关。[注意：如果您缺乏幽默感，您可能想要跳过很多内容。] 首先，我们的主服务器崩溃了。Linux 显然导致外部 SCSI 磁盘驱动器的电缆上的针脚断裂。然后，大约一周后，Linux 损坏了我们防火墙中磁盘驱动器的磁头。接下来，我们编辑的电脑里的风扇开始对她咆哮。最重要的是，办公室里的各种系统都在神秘地崩溃或表现出非常奇怪的行为。最终的结果是停机时间过长、电子邮件丢失以及与我们的计算机工作关系不愉快。

我们开始怀疑 Linux 是否对我们足够好，以及 Windows NT 是否可能支持“自动针脚重焊”和“磁盘头更换”。

一旦事情平静下来，我们仔细地查看了这些问题。顺便说一句，我们 特指我们的新系统管理员 Jay Painter、Peter Struijk 和我。首先，我们得出结论，硬件损坏可能不是 Linux 的错。尽管多任务操作系统在他们认为合适的时候就写入磁盘，这听起来很可怕，但这真的不是电缆断裂的原因。

为了解决停机时间比我们认为的要长的问题，让我们看看一些具体案例。

注意：此时，我们的各种系统运行着许多不同的软件版本（内核和 C 库），我们正处于将它们转换为 Debian 以便在所有机器上保持一致的过程中。

电缆故障导致服务器磁盘上的数据混乱。幸运的是，我们有文件的备份副本，所以这似乎是升级的好时机。我们做出了符合逻辑的决定，重新加载一个标准的 Slackware 系统（而不是尝试更改为 Debian），恢复用户文件，然后继续前进。结果证明这并不容易。新加载的 Slackware 与旧版本的差异比我们预期的要大。库不同了。NFS 和 NIS 不同了。我们用于制作参考卡的 Adobe 字体必须重新加载。groff 的配置文件必须更新。为了使新配置与所有旧系统对话并使一切都得到调整，做了很多工作。

可能是受到服务器停机期间防火墙额外工作的启发，下一个周末防火墙中磁盘上的磁头坏了，导致大量邮件丢失。为什么会丢失？为什么没有排队然后转发？这是 Linux 的另一个缺点吗？

经过调查，我们发现备用 MX（邮件交换器）记录已到位，以解决这个问题；但是，它们指向了错误的机器。同样，问题不能归咎于 Linux；这是一个以前的系统管理员的管理错误。这个错误没有被发现，因为这个备份以前从未被执行过，因为 Linux 一直运行良好。

让我们继续讨论我提到的那些 奇怪的软件问题。当然，我们可以在这里找到一些可以归咎于 Linux 的东西。

一台用作我们的 DNS 名称服务器的机器一直不太可靠。特别经常发生两件事。第一件事是 syslogd，系统日志守护进程，会挂在一个循环中，耗尽所有可用的 CPU 时间。虽然这个问题似乎与日志文件位置消失（由文件服务器重启或网络问题引起）有关，但我们一直无法修复它。然而，它似乎不会在新版本的 Linux 中发生（我们的问题机器运行的是 1.2.13），虽然它很烦人，但它不会导致机器崩溃——只是运行速度比正常速度慢。

这台机器上的另一个问题更奇怪，尽管事实证明它是可以修复的。即使在启动时只启动了一个 crond（cron 守护进程），机器上还是不断出现多个 crond 副本。有一天，我发现有 13 个 crond 作业正在运行，杀死了 12 个，几个小时后，发现还有三个在运行。

此时，Jay 开玩笑地说：“也许有一个 cron 作业正在启动 cron 作业。” 好吧，由于 cron 正在启动其他机器上不存在的进程，我开始四处寻找可疑的作业。我找到的前几个无关的作业是良性的，但后来我找到了一个作业，让我们俩都意识到 Jay 的玩笑尝试根本不是玩笑。事实上，有一个 cron 作业启动了另一个 cron 作业。或者更准确地说，一个 cron 作业 grepped 除了 cron 作业之外的所有内容，试图杀死所有 cron 作业，然后启动一个新的 cron 作业。换句话说，它看起来像一个部分编写的脚本，用于“谁知道是什么”——实际上什么都不会起作用。它被签名并注明了日期，所以我们可以看到是谁编写的，以及创建日期大约是稳定性问题首次出现的时候。再次，我们发现了“人为错误”，而不是 Linux 的问题。

有更多的故事，但空间有限，无法讲述。基本上我们发现的是，即使各种发行版可能在其中有一些缺陷，比如安装时文件权限错误，但它们都可以安装。Caldera、Linux FT、Debian、Red Hat、Slackware、Yggdrasil 和所有其他发行版都是如此。软件不会 磨损。如果系统正在运行，除了硬件错误之外，它不太可能停止运行。举个例子，我仍然在 fylz.com 的主机器上运行着一个 0.99 内核，它是在 1993 年 8 月安装的。它是一台 NFS 服务器，上面有三个 38.8KB 调制解调器。硬件是一台 386DX40，配备 8MB 内存。为什么我没有升级它？它工作正常，而且非常稳定。上次重启是在 1996 年 11 月，当时我关闭了机器以从 SCSI 总线上移除一个 zip 驱动器。

我们现在已经恢复运行，并继续我们的 Debian 转换。我们正在修复我们发现的问题——不仅是硬件和软件，还有管理方面的问题。例如，如果我们能够找到我们的 ISP 的手机号码，我们本可以比通过从一个基本上坏掉的系统发送电子邮件进行沟通更快地解决一些问题。

在我深入细节之前，让我说，无论您运行什么软件，都很难围绕硬件故障进行编程。检测和阻止它们是您能做的最好的事情。

您还可以进行备份和文档记录。在某个时候，我们有一个用于防火墙的配置磁盘；但是，当我们需要更换硬盘时，配置磁盘消失了。这种丢失花费了数小时的工作时间和可能一天的正常运行时间。拥有所有内容的完整备份、所有机器的启动盘、备用电缆和磁盘驱动器以及其他各种零件可以大大缩短处理问题的耗时。

我们缺少的另一个基本要素是监控系统。如果周日凌晨 3 点发生故障，可能要到周一早上 8 点才会注意到。能够立即检测到问题对于及时修复问题至关重要。即使只是一个人的工作站，在用户周一来上班之前修复或更换它，也会使网络的有效可靠性大大提高。

我们正在研究的另一项创新是备份文件服务器，用于执行每日备份。脚本会将每个人的主目录复制到这台机器上，然后将其磁盘写入磁带。然后，如果主服务器发生故障，我们可以将这台机器移入以接替主服务器。

另一个似乎仍然存在问题的东西是可靠的自动挂载守护进程。虽然我们已经半成功地运行了 AMD，但在我们的配置中，它已被证明有些不稳定。AMD 依赖于 NIS，并且已经发生过由物理网络或 yp 服务器引起的故障。

为了解决这个问题，Jay 有一个想法。请注意，这仍然是一个想法，而不是设计规范，但值得一提。以下是他的话

对于那些不熟悉它的人来说，VFS 是用户和正在支持的实际文件系统之间的接口层。这使得 DOS、System V 和其他文件系统的实现比在没有 VFS 的系统上容易得多。使用 VFS 实现自动挂载文件系统应该相对容易，并且它可以为困扰许多操作系统的难题提供一个集成的、可靠的解决方案。

另一件好事是日志文件系统 (JFS)。Unix System V Release 4 有一个，它可能是 SVR4 优于 Linux 的一个地方。由于这是一篇社论而不是技术文章，让我们只说 JFS 维护了足够的信息来重建崩溃后的确切文件系统结构，而无需恢复到 fsck 使用的那种 查找并销毁 方法。这意味着丢失任何东西的可能性更低，并且崩溃后重启时间更快。

这就是我这边的全部内容。如果有人对从事最后两个项目中的任何一个感兴趣，请给我发消息至 phil@ssc.com。也许我们可以比所有人做得更好。