Question

我写了一个脚本，它已经作为一个守护进程运行了很长一段时间了。如果我需要调试它，我会停止守护程序版本并在当前shell中手动重新运行。我从来没有记录过这个脚本的任何内容，但是当我准备将它部署在远程服务器上时，我想我想记录脚本会遇到的任何错误。出于这个目的，我遵循了几个SO帖子的提示，并且我正在做以下事情：

if ! tty > /dev/null; then
  exec > >(/bin/logger -p syslog.warning -t mytag -i) 2>&1
fi

这似乎记录得很好，我很惊讶在启用此功能时ps列出了我的脚本的两个实例。有没有办法避免它？

我知道我为logger获得了另一个流程，我认为它与>(...)有关，但仍然希望避免它

Answer 1

bash生成一个子shell来执行>( ... )中的命令。在这种情况下，subshell唯一做的就是运行/bin/logger，所以它是毫无意义的。我想你可以用另一个exec命令“修复”这个：

if ! tty > /dev/null; then
    exec > >(exec /bin/logger -p syslog.warning -t mytag -i) 2>&1
fi

这不会阻止子shell启动，但是不会将/bin/logger作为子进程（子shell）运行，而是将子shell替换为/bin/logger。我没有使用logger对此进行测试，但是在我使用cat进行的快速测试中它运行良好并且似乎工作正常。

Answer 2

查看PPID列。（父进程），我想你会看到这两个进程相互连接。

通常由'（）'对包围的命令表示'运行为子进程'，因此在ps中有2个列表，因为是 2个进程副本。（我不熟悉bash语法exec > **${spaceChar}** >( .... ) 2>&1，意思是'＆gt;'与第二个'＆gt;'中的空格隔开了）

crontab条目有什么问题？

为什么我最终得到两个进程？

2 个答案: