耗时很长的程序忘加nohup就运行了怎么办？
在 NGS基础：测序原始数据下载 一文中提到可以使用 SRA-toolkit 中的命令 fastq-dump 从NCBI下载原始测序数据，命令如下。
nohup fastq-dump -v --split-3 --gzip SRR5908360 &
nohup fastq-dump -v --split-3 --gzip SRR5908361 &
这个代码，给我们4个提示：
- fastq-dump 不只可以转换下载好的 sra 文件为 fastq 文件，还可以顺带下载 sra 文件。 只需提供 SRR 号，就可以获得 FASTQ 序列。 不需要先调用 prefetch 下载，然后再转换。 其它参数解释见引用文章。
- 每一行命令后面 & 号表示把命令放入后台运行，当前终端可以继续输入其它命令； 此处也相当于实现了一个手动并行下载多样本，配合 for 可以自动并行下载。
- nohup 表示让程序在终端因人为原因或网络原因断开后不挂断，适用于运行时间比较长的命令，一般与 & 连用，形式如 nohup 你的命令 & (注意空格的存在)。 如果程序运行输出错误信息，则会写入当前目录下 nohup.out 文件里面，供后续查看和调试。
- 经常会有一些培训班“拿来主义”比较严重，以上推文和生信宝典的其它推文都被发现过直接用于某些培训班的教材，但从未申请过授权，也未引用过出处。 更有甚者，盗版易生信早期培训教案和视频，用于自己的课程或在全网发布，希望大家多多举报。
言归正传，通常我们运行程序前，会有个预判，如前面那个例子，运行时间比较长，会使用 nohup 我的命令 & 的形式进行运行，从而保证程序不受网络或终端异常退出的影响。
但有时也会有误判，如没想到某个程序运行了半个小时还没结束，或数据传输时网太慢，需要传输很久，这时怎么办？中止程序，然后加上 nohup 再从头运行？还是有更好的办法？
下面看这个例子：马上要去吃午饭了，把文件同步到另一个服务器，饭后回来继续操作：
ysx@ehbio:~/test/Bigwig$ rsync -av * ysx@46.93.19.14:/tmp
ysx@46.93.19.14's password:
sending incremental file list
test1Y_DK10.bw
输入密码后，发现同步速度太慢了， 1 分钟只同步了 1 个文件，后面还有 99 个文件，待会离开后，如果网断了，终端退出，程序终止怎么办？同步不能完成，饭后怎么愉快的工作？
还好我们有下面的方案，一步步跟着操作，补救一下。
第一步，按 ctrl+z 把程序挂起，操作后屏幕会出现如下提示( [1] 中的 1 表示命令的作业号，后面会用到)：
^Z
[1]+ 已停止 rsync -av * ysx@46.93.19.14:/tmp
第二步（可选），用 jobs 命令查看下任务状态，跟刚才的屏幕提示一致，程序被暂时终止，作业号还是 1 ：
ysx@ehbio:~/test/Bigwig$ jobs
[1]+ 已停止 rsync -av * ysx@46.93.19.14:/tmp
第三步，使用 bg %1 命令把作业号为 1 的任务放入后台，并从 停止状态变为 运行状态，相当于加了 & 后接着运行。再用 jobs 查看，任务状态变成了 运行中 ，这一步很关键。如果没有运行 bg %1 则程序处于停止状态，一直不会运行，吃几顿饭都不会运行。
ysx@ehbio:~/test/Bigwig$ bg %1
[1]+ rsync -av * ysx@46.93.19.14:/tmp &
ysx@ehbio:~/test/Bigwig$ jobs
[1]+ 运行中 rsync -av * ysx@46.93.19.14:/tmp &
第四步，运行 disown -h %1 ，表示在终端关闭时不对作业号为 1 的程序发送终止信号，外部因素将不影响程序的运行。通过 ps 命令查看下任务进程 (可选)。
ysx@ehbio:~/test/Bigwig$ disown -h %1
ysx@ehbio:~/test/Bigwig$ ps -auwx | grep 'rsync'
ysx 18214 0.0 0.0 117844 1720 ? S 09:43 0:01 rsync -av *.bw ysx@46.93.19.14:/tmp
ysx 18215 0.1 0.0 182376 8360 ? S 09:43 0:04 ssh -l ysx 46.93.19.14 rsync --server -vlogDtpre.iLsfxC . /tmp
ysx 18340 0.0 0.0 112724 984 pts/1 S+ 10:17 0:00 grep --color=auto rsync
通过以上4步就完成了对这次操作的事后补救。以后遇到同类问题，试一试这个新方案吧！
同时还有5点提示：
- 例子中使用的是 rsync 同步，从节省时间来看，不是一个很好的例子。 因为把命令停掉再运行一次时，已经同步完整的数据不会再同步，时间损失不会太大。 这也是使用同步命令 rsync 相比于 scp 的一个好处。 更多同步方式见(。
- 例子中的 rsync 或其它涉及两个服务器交互的命令，都需要我们人为输入登录密码，因此直接加 nohup & 运行是行不通的，无法接受密码的输入。 因此通过上面这个操作先在前台启动运行、输入密码，再放入后台不挂断运行。 从这个角度看，是一个不错的例子。 当然解决这个问题也有其它方式，具体见。
- 如果程序运行时，已加了 & 号，放入后台了，则只需运行 jobs 获得作业号，再运行 disown 不挂断即可。
- 程序作业号不一定都是 1 ，如果之前就有程序在后台运行，作业号相应的会自加。 后面用到作业号时也需要相应修改，不要刻板总用 1 。
- nohup 和 disown 都可以使程序不挂断，可以获得一样的效果，但原理不太一致。 nohup 可以使程序忽略挂断信号( SIGHUP )或者使程序脱离终端的控制，从而终端不能再对其发送挂断信号( SIGHUP )； disown 则是内生于 shell ，告诉 shell 在终止时不对对应程序发送挂断信号( SIGHUP )。
