背景
背景知识1：
执行远端可执行文件时（RPC），为了操作的简便，将多步（ssh连接+定位并执行文件）放到一段shell脚本中；多见 ssh xxx@111.111.XXX “command/Executable file” 形式
背景知识2：
摘自 man 手册 ssh 命令的一段描述
==> If a command is specified, it is executed on the remote host instead of a login shell.
译 如果ssh命令后带有命令参数，那么这条命令就不会当做远程登录来执行。
问题场景
问题：远端（ssh 连接目的端）运行的程序（ssh 的命令参数指向）无法感知客户端（ssh 连接发起端）断开，因此 无法及时执行客户端所传递的中断命令，进而执行相关的异常处理、资源释放。
现象分析
1.ssh+command 形式远程执行文件时，目标主机 who 打印出的登录用户中不包括当前机器，可以认为本地机器并没有真正登录；
2.监听了 ssh 的目标机器的 ip，以两种形式（有/无 command 参数）执行 ssh 命令，可以明显看到两端交换的 ssh 协议数据包次数明显不同（带 command 参数 交换了更少的 ssh 包，由于 ssh 包非明文，无法得知具体内容）；退出 ssh 连接时，数据交换结果与登录时类似，相较缺少数个 ssh 协议的数据包交换。
3.在远程执行的程序中监听了几乎所有常见的信号，但客户端断开都没有立即触发任何一种。
解决
失败尝试思路 ： 切入点是 ssh 的断开感知，有 linux 基础的同学首先会想到用捕获相关信号来实现，即 SIGHUP 信号；背景知识：ssh连接+执行可执行文件或脚本操作，可拆分成==>启动 ssh 进程进行管理用户登录状态，创建一个以 ssh 进程为大佬的进程组 A，紧接着创建进程来执行可执行文件或者脚本，创建的进程加入进程组 A。此时若断开 ssh 连接，ssh 进程和其所在进程组的所有进程都将收到信号 SIGHUP ，该信号可拦截，信号的默认动作是使进程退出。
失败原因分析 ： 带 command 参数的 ssh 命令并不是真正建立 ssh 连接，也就没有相应的 ssh 进程以及进程组的存在，所以试图通过捕获 SIGHUP 信号来感知断开是无效的。
成功尝试 ：问题出现的场景是开发人员远程执行打包机上的打包机程序，打包机程序在执行过程中会不断的输入 log，并通过建立的 PIPE 不断传输 log 到打包的请求端主机。因此分析，若打包机程序输出log足够密集的话，请求端主机关闭PIPE 后，写入 PIPE 的信息发送至请求端时，会立即收到 SIGPIPE 信号，经过捕捉信号发现进程确实会收到 SIGPIPE 信号，且其默认动作是终止进程。但经观察，程序的 log 输出不连续，因此造成 SIGPIPE 信号页不能及时反映出请求端的断开时刻；因此，针对这一特点 =.=
尝试成功原因 ：由于log不及时，可以在打包程序中加入任务定时输出信息，暂用每秒输出内容 “\b\r” 到远端，这样既不影响连接端的log显示，又能及时（精度一秒）捕获到客户端断开了。
SIGPIPE 原因（以下指打包机端为服务端）：
客户端进程被杀死时会释放进程的资源，与远程建立 PIPE 的套接字会发送 FIN 至对端套接字，正常情况下对端回复 ACK，此时客户端认为当前连接已经关闭，然后释放自己的套接字资源；而服务端只是确认了客户端的 FIN ，只认为当前连接时半关闭状态，于是有新的输出时依旧向当前套接字中写数据，此时已经释放的客户端接收到数据时，由于套接字已经释放，无法接收信息，回复了一个reset包给服务端套接字，此时服务端应该就此判断出对方已经关闭，而释放掉套接字；否则执意向此套接字写数据，则写操作会返回 EPIPE 错误，并且进程收到 SIGPIPE 信号。
总
解决问题的思路是：接收系统进程 ssh+command 的状态或者相关信号，又因远程执行程序的通信渠道是管道，因此就 SIGPIPE 信号展开；就现状来看信号无法主动触发，因此需要设法手动触发信号。
实现方式 相当于在服务端加入了类似定时发送 keep alive 报文。
