我是 Linux 的新手，所以我有直觉，这个答案是微不足道的，但在寻找答案几天后，我放弃了，并指望你的帮助...
我在 CentOS 7 上使用软件。当我在 TTY 伪终端(例如/dev/tty2)上启动它时，它会在屏幕上打印出很多我需要分析的有趣信息。由于信息量大和存档，我想将它们保存在一个文件中。所以很明显我试图将 stdout、stderr 重定向到一个文件，但事实证明我只能保存终端屏幕上可见信息的一小部分(数百行)。后来我使用 strace 来弄清楚应用程序在屏幕上打印这些信息的方式——它正在写入/dev/tty0 设备(不是/dev/tty，而是/dev/tty0，当前可见的控制台，这使得 - 我认为 - 一个巨大差距)。意识到这一点后，我尝试了许多可能的解决方案来捕获此输出，包括:
- 屏幕 session 并记录到文件
- 用 python 编写的用于捕获 tty 写入的包装器 (How to redirect a program that writes to tty?)
- 使用“脚本”命令调用软件
对于捕获/dev/tty 写入来说一切都很好，但对于/dev/tty0 却不行!
您能提出任何解决方案，甚至只是一个我可以尝试的想法吗？
最佳答案
对于那些可能感兴趣的人......经过几周的实验，我分享我学到的东西:
强制预加载方法 - 一种简单快捷的方法，但在我的案例中有一个主要缺点 - 它实际上不拦截系统调用，而是拦截 libc 标准库调用。缺点，因为应用程序可以绕过库直接调用系统调用，并且不会被拦截。它发生在我的案例中。
后来，我尝试了内核模块，相对较快地，我可以通过修改 syscall_table 中的系统调用函数地址来创建具有拦截系统调用的基本模块(需要一些肮脏的技巧，例如使用 CR0 寄存器操作取消保护写入该内存等。 .)，但更多的是我试图取得进展，我遇到了更多的问题，特别是在拦截子进程的上下文中，我也想拦截 fork 进程的系统调用。当然，最大的好处是您可以最终访问任何内核结构等...一段时间后，我放弃并尝试了第三种选择。
Ptrace 方法 - 乍一看似乎很复杂，但很有逻辑性，但您需要阅读冗长的文章才能理解。同样，对于 fork 进程，事情变得复杂，但我现在接近于创建可行的解决方案，PTRACE_O_TRACEFORK 等东西很有帮助。
我的结论 - 为此创建通用解决方案无论如何都不是一件容易的事情(例如查看“strace”源代码......)，对我来说 ptrace 是最好的选择，但是你需要花一些时间来理解它，特别是对于 fork 进程。
结论号2 - 尝试解决这个问题对我来说是一次伟大的冒险，深入 linux 内核以及 syscall 的工作原理是一次了不起的学习:)
感谢 melpomene 的启发! :)
关于linux - 捕获/dev/tty0 输出到文件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52036650/