使用 start-stop-daemon 时 autossh pid 不等于 pidfile 中的 pid答案

【问题标题】：autossh pid is not equal to the one in pidfile when using start-stop-daemon使用 start-stop-daemon 时 autossh pid 不等于 pidfile 中的 pid
【发布时间】：2016-03-09 18:24:07
【问题描述】：

我正在尝试在我的 Debian Wheezy 系统上创建服务。

尝试使用start-stop-daemon运行autossh时，pidfile中包含的pid与autossh进程不匹配。

$ AUTOSSH_PIDFILE=/var/run/padstunnel.pid
$ sudo start-stop-daemon --make-pidfile --background --name mytunnel --start --pidfile /var/run/mytunnel.pid --exec /usr/lib/autossh/autossh -- -M 0 -p 22 user@server -f -T -N -R 31022:localhost:31222
$ ps -elf |grep autossh
1 S root       447     1  0  80   0 -   329 pause  19:07 ?        00:00:00 /usr/lib/autossh/autossh -M 0 -p 22 ...
$ cat /var/run/mytunnel.pid
446

此行为可防止使用 start-stop-daemon 停止 autossh 或使用 pidfile 中的 pid 将其终止。

这种行为有什么原因吗？

如何解决它并使 autossh 的 pid 与 pidfile 匹配？

【问题讨论】：

您是否尝试过设置AUTOSSH_PIDFILE 变量并让autossh 自己编写pid 文件？
是的，结果相同
那是因为-f 告诉 autossh 进入后台。（即叉子）。尝试删除它。
去掉 `-f` 选项也不好用：然后 autossh 创建了两个进程，pidfile 的 pid 与 root 进程不匹配。在我找到的答案中查看更多信息。

标签： linux ssh debian autossh

【解决方案1】：

我找到的解决方案灵感来自this answer。

实际上，autossh 无法使用 AUTOSSH_PIDFILE 变量（因为 start-stop-daemon 在不同的环境中运行）。

所以解决方法是使用：

$ sudo start-stop-daemon --background --name mytunnel --start --exec /usr/bin/env AUTOSSH_PIDFILE="/var/run/mytunnel.pid" /usr/lib/autossh/autossh -- -M 0 -p 22 user@server -f -T -N -R 31022:localhost:31222

/usr/bin/env AUTOSSH_PIDFILE="/var/run/mytunnel.pid" 正确定义了必要的环境变量
start-stop-daemon 不再需要 --make-pidfile 和 --pidfile
sudo start-stop-daemon --pidfile /var/run/mytunnel.pid --stop 现在可以杀死 autossh
--background 选项使ssh 的-f 可选（如果使用--background，则使用-f 不会改变任何内容）

这种行为的原因对我来说并不完全清楚。但是，当autossh 没有看到AUTOSSH_PIDFILE 变量时，似乎autossh 会自动创建几个进程来正确处理ssh 实例。

编辑：

从服务初始化脚本（在 /etc/init.d/servicename 中）使用它时，必须修改语法：

sudo start-stop-daemon --background --name mytunnel --start --exec /usr/bin/env -- AUTOSSH_PIDFILE="/var/run/mytunnel.pid" /usr/lib/autossh/autossh -M 0 -p 22 user@server -f -T -N -R 31022:localhost:31222

注意-- 必须紧跟在 /usr/bin/env 命令之后（它在命令行的 /usr/lib/autossh/autossh 之后）。

【讨论】：