linux - 在 BASHRC 与命令行中启动后台进程之间的区别

Question

我正在尝试自动将进程置于后台。

nohup program > /tmp/program.log 2>&1 < /dev/null &
disown

如果我检查进程是否正在运行并通过“.bashrc”在登录时启动它，程序会启动但在我退出时死掉。

但是如果我在命令行上执行完全相同的命令，程序会在我退出时继续在后台运行。

我找不到 bashrc 启动和 cli 启动之间的程序环境有任何区别。 (bashrc 中几乎没有任何内容)。我对这两种情况下的程序的理解应该一视同仁。

有什么区别，我怎样才能阻止 bashrc 启动的“守护进程”在 shell 退出时被杀死。

PS:删除 nohup 没有任何区别。当开始登录退出时，我看到程序运行然后从单独的登录中消失。

在有人说什么之前...在 bashrc 中将程序后台化后添加“disown”并没有解决它!

更新: 如果 ssh 登录连接被终止(窗口关闭或连接突然终止)，bashrc 中启动的程序将继续运行，但这似乎是因为启动它的 bash 也在运行(至少暂时如此)。仅当您为 bash 键入“exit”或 bash 被杀死时(即使是无法捕获的信号 9!)，背景才会被杀死。

程序的 PPID(由 shell 否认)是 0，它的父进程不是 shell 也不是 init 进程!不管它是如何开始的，都是这种情况。

更新 2...后台程序从bashrc启动...

# ps -jA w
   PID   PGID    SID TTY      STAT   TIME COMMAND
   891    891    891 pts/2    Ss+    0:00 /bin/bash
   899    891    891 pts/2    Sl+    0:00 program

我杀了那个然后从命令行启动它...

   891    891    891 pts/2    Ss+    0:00 /bin/bash
   958    955    891 pts/2    Sl     0:00 program

现在，当 shell 存在时，程序不会退出。所以看起来唯一不同的是 PGID 改变了。

如何在不同的 PGID 中启动进程？

Answer 1

作业控制需要进程组，因为 shell 需要一些东西来发送作业控制信号，例如当你输入 fg . POSIX.1-2017 states

A command interpreter process supporting job control can allocate the terminal to different jobs, or process groups, by placing related processes in a single process group and associating this process group with the terminal

(斜体是我的)这似乎甚至等同于“进程组”和“作业”的概念，尽管大多数人使用术语“作业”来表示进程组(甚至是 shell 自己的进程组中的子进程)在 shell job table 中注册(并且可以通过内置 disown 从该表中删除)

因此，如果 shell 不想在作业控制下启动子命令(甚至 shell 管道)，它不会创建新的进程组(通过调用 setpgrp() )

这发生在例如使用进程替换时

blah=$(sleep 1000 | sleep 1000)

(尝试一下，看看 ps -jA w 的输出!)显然，当从 .bashrc 开始命令时

nohup <command> , 本身不会启动一个新的进程组，它只会 ignores SIGHUP然后执行 command

Linux(和其他操作系统，当你安装类似 util-linux 的东西时)有一个命令 setsid那将do what you expected (但没有得到)来自 nohup : setsid command将create a new process group对于 <command>并使其成为新 session 的 session 负责人。 PGID调用者不知道这个新进程组的名称(在本例中为 bash)，因此我们不需要使用 nohup不再。

所以，使用 setsid而不是 nohup然后你就完成了(我现在才看到 Mark Plotnick 的评论，这是对的。哦，好吧，我希望我的回答也澄清了为什么 setsid 在这种情况下是更好的选择的原因 )