脚本中保持FIFO打开时Telnet连接异常关闭或命令无法发送

核心问题根源 #

• FIFO的读取端（比如你用的cat my1.fifo）会在所有写入端关闭时立即退出，导致Telnet的标准输入被切断，直接触发连接关闭。脚本批量执行时，后台的cat >my1.fifo很可能因脚本退出收到SIGHUP信号终止，或者Python脚本写完命令后没保持FIFO打开，都会触发这个问题。
• 三个后台进程是并行启动的，没有同步机制。Telnet可能还没完成连接，Python脚本就发了命令，导致命令丢失；或者FIFO读取端还没就绪，写入操作直接失败。

具体修复步骤 #

1. 持续保持FIFO写入端打开 #

别用cat >my1.fifo &这种临时进程，它很容易退出。换成tail -f /dev/null >my1.fifo &，这个进程会一直挂着，持续保持FIFO的写入端打开，彻底避免读取端因写入端关闭而退出。

2. 同步进程启动顺序 #

必须等Telnet完全建立连接、就绪后，再启动Python脚本发命令。可以通过检查日志里的特征字符串判断（比如Telnet登录成功的提示，你得换成自己环境里的实际内容）：

# 先创建FIFO（如果之前没建）
mkfifo my1.fifo

# 启动Telnet，直接从FIFO读输入，不用cat转发（减少中间依赖）
telnet 172.27.172.247 10031 < my1.fifo > log.txt 2>&1 &
TELNET_PID=$!

# 等待Telnet就绪，比如等日志出现"Login OK"（替换成你的实际提示）
until grep -q "Login OK" log.txt; do
    sleep 1
done

# 启动Python脚本
python3.10 strrr.py &

# 保持FIFO写入端持续打开
tail -f /dev/null >my1.fifo &

3. 防止后台进程被SIGHUP信号终止 #

脚本执行完退出时，会给后台进程发SIGHUP信号，导致进程被kill。可以用nohup包裹后台进程，或者在脚本开头加trap "" HUP忽略SIGHUP：

# 忽略SIGHUP信号
trap "" HUP

mkfifo my1.fifo

telnet 172.27.172.247 10031 < my1.fifo > log.txt 2>&1 &
until grep -q "Login OK" log.txt; do
    sleep 1
done

python3.10 strrr.py &
tail -f /dev/null >my1.fifo &

4. 直接让Telnet读FIFO，去掉中间cat进程 #

原来的cat my1.fifo | telnet ...多了一个中间进程，一旦cat退出，Telnet输入就断了。换成telnet ... < my1.fifo，让Telnet直接从FIFO读取输入，减少故障点。

内容的提问来源于stack exchange，提问作者Anubhav Rai