Pty仍然保持打开状态，尽管进行了close()系统调用

本篇文章向大家介绍《Pty仍然保持打开状态，尽管进行了close()系统调用》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

我正在实现 ssh 服务器的功能，因此根据 shell 请求，我打开一个 pty-tty 对。

片段：

import (
    "github.com/creack/pty"
    ...
)

func attachPty(channel ssh.Channel, shell *exec.Cmd) {
    mypty, err := pty.Start(shell)
    go func() {
        io.Copy(channel, mypty) // (1) ; could also be substituted with read() syscall, same problem
    }
    go func() {
        io.Copy(mypty, channel) // (2) - this returns on channel exit with eof, so let's close mypty
        if err := syscall.Close(int(mypty.Fd())); err != nil {
            fmt.Printf("error closing fd") // no error is printed out, /proc/fd shows it's successfuly closed
        }
    }
}

一旦 ssh 通道关闭，我就关闭 pty。我预期的行为是它应该向 shell 发送 sighup。

如果我注释掉 (1) 副本（src：mypty，dst：channel），它就可以工作！

但是 - 当它没有被注释掉时：

• (1) 副本未返回，这意味着来自 mypty 的 read 系统调用仍处于阻塞状态，并且不返回 eof => 主设备未关闭？
• shell 没有收到 sighup

我不确定为什么如果我注释掉 (1) 副本它会起作用，也许内核引用会对读取进行计数？

我的线索：

• pty.read 实际上被分派到 tty，如： pty master缺少读取功能
• sighup 流程演练
• drivers/tty/pty.c 中的 pty_close，它调用 tty_vhangup(tty->link);，请参见此处
• linux 设备驱动程序，第 3 版，pty 章节

去笔记：

• 我直接关闭 fd，因为否则使用通常的 os.file.close() 实际上并不会因为某种原因关闭 fd，它在 /proc//fd 中保持打开状态

• 用直接的 read 系统调用替换 (1) 副本将导致相同的结果

谢谢！

正确答案

我自己也遇到过这个问题，并花了一些时间进行调查。

事实证明，这是 Go 运行时的故意行为。具体来说，它可以防止文件被关闭 while they are being read by another goroutine。这是在 mitigate a race condition 中引入的，如果文件描述符被关闭并被另一个 goroutine 重用，则 goroutine 可能会从错误的文件中读取。

对于 SSHD 用例，我没有好的解决方案。我稍后可能会更新这个答案。您自己想出了一些解决方法吗？

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。