使用制表符完成的“只读文件系统”错误，并且终端窗口随机关闭

首先只是简单的命令cd。如果输入cd，然后输入一个空格，然后按Tab查看可用目录，则会收到以下错误消息：

bash：无法为此处文档创建临时文件-文档：只读文件系统

更麻烦的问题是终端窗口的随机关闭。测试cd奇数时，以及将ssh放入另一台服务器执行诸如此类的简单操作时git status，都发生了这种情况。[编辑]看来，如果我按Enter正好31次，它会触发终端窗口的自动关闭（现已验证3次）。

我最近在上周晚些时候从12.04升级到14.04，并且升级后的整个一天都没有发生这种现象。自那天以来，这是第一次在这台计算机上尝试任何操作。

请告知我可以提供的任何其他信息，以及解决该问题所需采取的措施。

我以恢复模式重新启动，并按照系统给我的指示进行操作。我跑fsck的/dev/sda2，而且解决了这一问题。

该Read-only file system错误是在这里的主要线索。我想您的bash试图存储您的命令历史记录等的主目录位于只读分区中。

我猜想它会尝试每32条命令一次更新磁盘上最近的命令历史记录，这就是为什么在会话中键入的第32条命令失败的原因。

现在，如果您故意将分区挂载为只读，但是如果出现错误，也可以将其挂载为只读-后者的行为通常是根分区的默认设置。

如果您的根分区以只读方式挂载，如果您没有遇到其他问题，我会感到惊讶。

您可以尝试重新启动并从恢复菜单中检查磁盘。在计算机启动时按住Shift键，紧接着在BIOS屏幕消失之后并且在Ubuntu徽标出现之前。

这个确切的问题也发生在我身上。

它间歇地发生。

因此，我终于受够了，并决定重新安装操作系统-ubuntu-gnome 14.04（干净）。

它修复了！至少几天了。然后又发生了同样的问题...

因此，我去了Fry's并得到了一个新的HDD（希捷）。

到目前为止，一切都很好（6个月及以上）。

旁注：库存的硬盘是东芝

正如其他人指出的那样，只读/tmp文件系统会引起更多问题。

至于31行，则与gnome-terminal的内部相关。

它在所谓的“环”中将一定数量的行保留在内存中。其余的，从该环中滚动出来的行被置于“流”中。在gnome-terminal的旧版本中，流几乎直接写入到文件中/tmp，在新版本中，在写出之前先进行缓冲，压缩和加密。（我不记得/tmp是在将第一批数据写入流中时还是在流首次尝试实际写入时是否打开了下面的文件/tmp；这是次要的实现细节。）

环的大小始终是2的幂（每个插槽包含1条端子的线；由于技术原因不使用1个插槽），并且由于端子高度的增加，每次需要时都会加倍（但永不缩水）。例如，默认高度为24行，则环包含输出的最后31行，其余行进入流（最终到/tmp）。如果您将窗口的高度增加到40行，则内存环将逐渐增长，一次最多可容纳63个条目。

您遇到的是gnome-terminal尝试打开一个文件/tmp来存储流，然后由于意外失败而退出。尝试使用比默认值更高的窗口；按下Enter键63次（或127次）后，它将崩溃。

话虽这么说，/tmp应该固定为可写的（权限为1777）。

我的问题是，一个进程使用100％CPU运行，并且可能占用了所有磁盘资源（某些备份过程：Ur-Backup）。

一旦我杀了它，一切就顺利了。因此，我认为即使有足够的空间并且您具有写权限，IO上的瓶颈也可能导致此错误。

（Raspberry Pi和Jessy 18/03/16）