Ruby on rails Rails在通过tmux输出缓冲区进行搜索时冻结

我正在使用tmux以开发模式运行Rails 3.2.6。当我使用tmux滚动Rails服务器的输出缓冲区（使用Rails s运行）时，服务器冻结，不处理任何请求。当我退出回滚模式时，服务器会再次正常工作

---

如何设置我的服务器在查看输出缓冲区时继续处理请求？

如果您想在服务器继续处理请求时暂停并查看特定的日志消息序列，最好直接查看日志文件；您可以使用

less-R log/development.log

当tmux窗格处于“复制模式”（用于查看窗格历史记录的模式）时，tmux不会从窗格的tty中运行的进程读取任何输出。如果进程继续将输出写入tty，则操作系统的tty缓冲区最终将填满。当一个程序在缓冲区满的情况下写入tty时，它会导致进程阻塞，从而使缓冲区不会溢出；这就是导致服务器暂时停止处理请求的原因

时间线如下所示：

您进入复制模式以查看一些旧的输出。
tmux停止从tty读取数据

Rails服务器在处理正在进行的请求时，会继续向tty写入数据。
操作系统将这些写操作吸收到某个有限大小的tty缓冲区中

最终，OS tty缓冲区将填满，并导致对tty的进一步写入被阻塞。
这就是Rails服务器“冻结”的地方；它一直在等待操作系统从（例如）为显示日志消息而进行的写（2）调用返回

您将退出复制模式。
tmux恢复从tty读取，耗尽缓冲输出并接受新输出

---

除了不使用tmux之外，还有什么办法可以解决这个问题吗？@justingordon：如果在tmux窗格中运行的程序在窗格处于“复制模式”时写得足够多，那么它最终会被阻塞。如果您需要查看一个长时间运行的聊天进程的输出，最好将输出发送到日志文件，并使用

less

之类的方法查看输出，而不是使用tmux的“复制模式”。在iTerm2中运行txmux是解决此问题的一种方法。@justingordon:您的意思是使用iTerm2提供的tmux集成吗？我不使用它，但如果iTerm保留自己的窗格历史记录副本，用于查看“回滚”，那么这可能会起作用。它仍然认为使用“复制模式”会导致写入tty的进程阻塞。作为一种解决方法，我使用tail log/development.log-F在另一个窗格中运行rails时查看日志。