我有一个专有的 Linux 系统，带有专有的 init 系统，它使用串行控制台。我最近注意到，xon/xoff 流控制在此串行控制台上处于活动状态，当线路噪声接收到 xon 字符 (0x13) 时，这会带来挂起启动进程的风险。查看具有串行控制台（基于 systemd）的其他系统表明，串行控制台的流量控制被禁用，这看起来很正常。
问题是，系统的哪一部分负责停用控制台tty的流控制？这是由 init 进程还是内核本身完成的？即，这是内核配置中的错误还是必须修复 init 系统以禁用流量控制？
tcsetattr()我知道，可以使用该函数或通过运行来禁用流量控制stty -ixon -F /dev/console，但对于可靠的系统，应该在任何进程将输出写入控制台之前禁用它。我已经浏览了 systemd 源代码，但找不到任何禁用流量控制的代码。
答案1
承认我对你们专有的 Linux 系统一无所知，也不了解你们专有的 init 系统：
我最近注意到，xon/xoff 流控制在此串行控制台上处于活动状态，当线路噪声接收到 xon 字符 (0x13) 时，这会带来挂起启动进程的风险
就引导阶段（init 之前）而言，这对于任何普通 Linux 来说都是不可能发生的。原因很简单，无论其配置如何，内核在启动时都不处理软件流控制。
在启动时，内核可以处理硬件流控制（RTS/CTS），但前提是通过以下命令特别指示这样做：console启动命令行参数因为它不会默认。
您的引导日志应该告诉您引导命令行是否包含控制台的特殊设置。如果设置包含最终r（请参阅上面的链接）并且您的线路噪音足以生成虚假的 RTS/CTS...然后删除r从设置。
无论 init 都会愉快地继续这些设置，直到......它留给某些getty（或像：agetty、mgetty......）进程打开端口并设置所需的线路规则的责任。
在任何标准的 Linux 发行版下，这个过程都是阿吉蒂这将默认忽略硬件流控制，并且与其他类似进程相反，将激活软件流控制（XON/XOFF），如果发现不合适，则将禁用它的责任留给任何后续进程。
因此，您应该首先了解哪个进程正在处理您未登录的 tty。只需触发一些ps -ax命令并查找此类行（就像现在在我的系统上一样）：
1515 tty2 Ss+ 0:00 /sbin/agetty 38400 tty2 linux
如果如上所述agetty正在运行，那么，如上所述，您必须求助于stty您熟悉的命令（因为之后启动的 /usr/bin/login 进程agetty无法更改任何行规则）。
如果过程不同，则只需报告，可能有禁用软件控制流的选项。
当然，对于我自己在嘈杂的环境中使用串行线路来说……这只是噩梦，其中的一部分……虚假的 XOFF 只占很小的一部分。
如果您的线路噪音很大，请降低波特率。
安装 RS232/RS485 转换器救了我的命……;-)