ASPIRE

Linux下让进程在后台可靠运行的几种方法

=Start=

缘由：

我经常会碰到这样的问题，用 ssh 登录了远程的 Linux 服务器，运行了一些耗时较长的任务，结果却由于网络的不稳定导致任务中途失败。如何让命令提交后不受本地关闭终端窗口、网络断开连接的干扰呢？总结下来主要有以下3点需求：

  1. 想让进程在断开连接后依然保持运行？
  2. 如果该进程已经开始运行了该如何补救？
  3. 如果有大量这类需求如何简化操作？

下面主要针对以上这3点需求进行解答，内容基本上照搬「Linux 下让进程在后台可靠运行的几种方法」，略有精简。

正文：
0x0.为什么SSH断开后你运行的进程会退出呢？

因为所有进程都得有个父进程。当你ssh到一个服务器上时，打开的shell就是你所有执行命令的父进程。

当你断开ssh连接时，你的命令的父进程就没了。如果处理不当，这些进程就会收到SIGTERM信号，全被干掉了。

0x1.如何让进程在断开SSH连接后依然保持运行？

nohup 无疑是我们首先想到的办法。顾名思义，nohup 的用途就是让提交的命令忽略 hangup 信号。
nohup 的使用是十分方便的，只需在要处理的命令前加上 nohup 即可，标准输出和标准错误缺省会被重定向到 nohup.out 文件中。一般我们可在结尾加上”&”来将命令同时放入后台运行，也可用”>filename 2>&1″来更改缺省的重定向文件名。

nohup 无疑能通过忽略 HUP 信号来使我们的进程避免中途被中断，但如果我们换个角度思考，如果我们的进程不属于接受 HUP 信号的终端的子进程，那么自然也就不会受到 HUP 信号的影响了。setsid 就能帮助我们做到这一点。
setsid 的使用也是非常方便的，也只需在要处理的命令前加上 setsid 即可。

将一个或多个命名包含在“()”中就能让这些命令在子 shell 中运行中，同时将”&“也放入“()”内之后，我们就会发现新提交的进程的父ID（PPID）为1（init 进程的 PID），并不是当前终端的进程ID。因此并不属于当前终端的子进程，所以能躲过 HUP 信号的影响。

0x2.如果该进程已经开始运行了该如何补救？

只能通过 作业调度(CTRL-z/fg/bg) 和 disown 来解决这个问题。

0x3.如果有大量这类需求如何简化操作？

在 screen/tmux/byobu 中任选一个。screen/tmux/byobu都是虚拟多终端的工具。这些工具可以完成：

  1. 虚拟多个终端在一个ssh连接中；
  2. 断线后的恢复。

这里我们需要的是第2个功能。

总结：

nohup/setsid 无疑是临时需要时最方便的方法，disown 能帮助我们来事后补救当前已经在运行了的作业，而 screen/tmux 则是在大批量操作时不二的选择了。

参考链接：

=END=

admin

, , ,
, , , ,

《 “Linux下让进程在后台可靠运行的几种方法” 》 有 6 条评论

  4. 如何通过CRIU CHECKPOINT/RESTORE应用
    http://reborncodinglife.com/2018/05/29/checkpoint-restore-linux-application-by-criu/
    https://criu.org/Main_Page
    `
    criu 是Linux平台在用户空间实现checkpoint/restore功能的工具软件。通过该工具，可以冻结正在运行的应用程序或者其中的一部分，并将应用程序的执行状态以文件形式保存在磁盘上，然后通过这些快照文件，可以将应用程序从冻结的时间点恢复回来继续运行。借助该软件，可以实现应用的实时迁移、应用快照和远程调试等功能。criu最显著的特点是在用户空间实现checkpoint/restore，不需要修改应用程序的代码或者修改操作系统，并且也是内核中功能最丰富和最活跃的。
    `

    回复

  5. 用tmux分享内网里的终端
    https://briteming.blogspot.com/2018/05/tmux.html
    `
    在一台服务器上直接共享服务器上的 tmux 会话的例子已经有很多了， 实际操作可以参考使用 tmux 结对编程、 Remote Pair Programming Made Easy with SSH and tmux。

    如果要分享 NAT 内部的机器终端给不同 NAT 背后的电脑操作或者观看，可以实现吗？ 考虑到一位来自远古时期的开发者 Alice，她只在终端上开发，突然一天要转行做网红程序员了，就可能会有直播写代码的需求，而且她希望操作的是自己本地电脑的开发环境终端，直播分享给遍布全世界的拥趸观看。这时上面介绍的分享公网服务器上 tmux 会话的操作就行不通了。

    我对这类位于不同 NAT 内部的机器共享终端的问题想了下，发现结合 tmux 和反向 shell 是可以解决的，再对期间可能出现的权限问题进行分析，利用在跳板机新增一个中间用户及 tmux 的只读模式的方法，可以实现分享出去的终端对其余用户只能观看，无法获取写的操作权限，从而保证分享者主机的安全。

    首先，简单说下一些常用的反向 shell 的方法，它是分享 NAT 内网终端的前提。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注