unix - 如何在不获取 nohup.out 的情况下使用 nohup 命令？

Question

我的 nohup 命令有问题。

当我运行我的工作时，我有很多数据。输出 nohup.out 变得太大，我的进程变慢了。如何在不获取 nohup.out 的情况下运行此命令？

Answer 1

nohup命令仅写入 nohup.out如果输出否则会进入终端。如果您已将命令的输出重定向到其他地方 - 包括 /dev/null - 那就是它去的地方。

 nohup command >/dev/null 2>&1   # doesn't create nohup.out

如果您使用的是 nohup ，这可能意味着您想通过放置另一个 & 在后台运行该命令在整个事情的结尾:

 nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out

在 Linux 上，使用 nohup 运行作业也会自动关闭其输入。在其他系统上，特别是 BSD 和 macOS，情况并非如此，因此在后台运行时，您可能需要手动关闭输入。而关闭输入对 nohup.out的创建与否没有影响。 ，它避免了另一个问题:如果后台进程试图从标准输入读取任何内容，它将暂停，等待您将其带回前台并键入一些内容。所以额外安全的版本看起来像这样:

nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal 

但是请注意，这不会阻止命令直接访问终端，也不会将其从 shell 的进程组中删除。如果你想做后者，并且你正在运行 bash、ksh 或 zsh，你可以通过运行 disown 来实现。没有参数作为下一个命令。这意味着后台进程不再与 shell “作业”相关联，并且不会从 shell 向它转发任何信号。 (注意区别:一个 disown ed 进程不会得到其父 shell 自动转发给它的信号 - 但如果没有 nohup ，它仍然会收到通过其他方式发送的 HUP 信号，例如手动 kill命令。一个 nohup 'ed 进程忽略任何和所有 HUP 信号，无论它们是如何发送的。)

解释:

在 Unixy 系统中，每个输入源或输出目标都有一个与之关联的数字，称为“文件描述符”，或简称为“fd”。每个正在运行的程序(“进程”)都有自己的一组这些，当一个新进程启动时，其中三个已经打开:“标准输入”，即 fd 0，打开供进程读取，而“标准输出”(fd 1)和“标准错误”(fd 2)是开放的，可以写入。如果您只是在终端窗口中运行命令，那么默认情况下，您键入的任何内容都会进入其标准输入，而其标准输出和标准错误都会发送到该窗口。

但是您可以在启动命令之前要求 shell 更改任何或所有这些文件描述符指向的位置；这就是重定向( < 、 << 、 > 、 >> )和管道( | )运算符所做的。

管道是这些中最简单的... command1 | command2安排 command1 的标准输出直接输入到 command2 的标准输入中.这是一个非常方便的安排，导致了 UNIX 工具中的特定设计模式(并解释了标准错误的存在，它允许程序向用户发送消息，即使其输出正在进入管道中的下一个程序) .但是您只能通过管道将标准输出传输到标准输入；你不能在没有一些杂耍的情况下将任何其他文件描述符发送到管道。

重定向运算符更友好，因为它们允许您指定要重定向的文件描述符。所以 0<infile从名为 infile 的文件中读取标准输入, 而 2>>logfile将标准错误附加到名为 logfile 的文件的末尾.如果不指定数字，则输入重定向默认为 fd 0( < 与 0< 相同)，而输出重定向默认为 fd 1 ( > 与 1> 相同)。

此外，您可以将文件描述符组合在一起: 2>&1意思是“在标准输出的任何地方发送标准错误”。这意味着您会得到一个单一的输出流，其中包含标准输出和标准错误混合在一起，无法再将它们分开，但这也意味着您可以在管道中包含标准错误。

所以序列 >/dev/null 2>&1表示“将标准输出发送到 /dev/null”(这是一种特殊的设备，它只会丢弃您写入的任何内容)“然后将标准错误发送到标准输出的任何地方”(我们刚刚确定是 /dev/null) .基本上，“丢弃此命令写入任一文件描述符的任何内容”。

当 nohup检测到它的标准错误和输出都没有附加到终端，它不会费心创建 nohup.out ，但假设输出已经重定向到用户希望它去的地方。
/dev/null设备也适用于输入；如果您使用 </dev/null 运行命令，那么该命令从标准输入读取的任何尝试都会立即遇到文件结尾。请注意，合并语法在这里不会产生相同的效果；它只能将文件描述符指向另一个在同一方向(输入或输出)打开的文件描述符。 shell 会让你做 >/dev/null <&1 ，但这最终会创建一个在输出流上打开输入文件描述符的进程，因此任何读取尝试都将触发致命的“无效文件描述符”错误，而不是仅仅点击文件结尾。