有没有办法恢复/恢复 nohup 以在控制台中查看输出?

发布于 2024-10-03 19:10:00 字数 142 浏览 0 评论 0原文

我知道机会极低,但是有办法吗 查看 nohup-ed 进程最近输出了什么?

我仍然打开这个进程,但我已经将所有输出重定向到 /dev/null 来运行它。

那么有没有办法将这样的过程恢复到控制台,或者是没有希望了:(

干杯

I know chances are extremely low, but is there a way
to see what a nohup-ed process has been outputting recently?

I still have this process open but I've run it with redirecting all output to /dev/null.

So is there a way to recover such process back to console, or is it hopeless :(

Cheers

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

意中人 2024-10-10 19:10:00

有一种方法,但它不是直截了当的,技巧是使用 dup2 并取决于您的程序与 libc 链接的事实(所有 c/c++ 应用程序都是如此,但 java 应用程序不会是例如) )

  1. 使用 gdb 附加到您的进程
  2. 在 gdb 提示符下运行以下命令将 stdout 重定向到 /tmp/newfile

    $ print dup2(open("/tmp/newfile",0), 1)

  3. 运行以下命令将 stderr 重定向到 /tmp/newfile

    $ print dup2(open("/tmp/newfile",0), 2)

  4. 将 gdb 从你的进程中分离出来,你完成的

dup2 所做的是

复制文件描述符
这意味着 stdout/stderr(1 和 2)和从 open 返回的新文件描述符可以互换使用,这将导致所有发送到 stdout 和 stderr 的输出都发送到您打开的文件。

There is a way but it isn't straight forward, the trick is to use dup2 and depends on the fact that your program is linked against libc (which all c/c++ applications would be, but a java application wouldn't be for example)

  1. attach to your process using gdb
  2. run the following at the gdb prompt to redirect stdout to /tmp/newfile

    $ print dup2(open("/tmp/newfile",0), 1)

  3. run the following to redirect stderr to /tmp/newfile

    $ print dup2(open("/tmp/newfile",0), 2)

  4. detach gdb from your process and your done

What dup2 does is

duplicate a file descriptor
This means that both stdout/stderr (1 and 2) and the new file descriptor returned from open can be used interchangeable which will cause all output going to stdout and stderr to go to the file you opened.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文