标签: process

我有一个长时间运行的进程，最终会达到最大打开文件限制。我知道如何在它失败后更改它，但是有没有办法从命令行更改正在运行的进程？

假设我知道 pid，如何查看进程何时启动。（在 Linux 上）

我正在使用 Windows 任务管理器来跟踪 CPU 利用率。我注意到我的应用程序已列出，但 Windows 服务未列出。

例如，总 CPU 使用率被列为 70%，但列出的应用程序的摘要只有大约 30%。我认为不同之处在于 Windows 任务管理器的“进程”选项卡中未列出的服务。

有什么办法可以pgrep让我知道每个进程的所有信息ps吗？我知道我可以ps通过管道，grep但这需要大量打字，而且它还为我提供了grep我不想要的流程本身。

在与同事长时间讨论后提出这个问题，我真的很想在这里澄清一下。

我启动了一个后台进程，通过将“ &”附加到命令行或通过CTRL-Z使用“ bg”停止并在后台恢复它。然后我退出。

发生什么了？

我们很确定它应该被 SIGHUP 杀死，但这并没有发生；再次登录后，该进程愉快地运行并pstree显示它已被“采用”init.

这是预期的行为吗？

但是，如果是，那么nohup命令的目的是什么？看起来这个过程无论如何都不会被杀死，不管有没有它......

编辑 1

更多细节：

• 该命令是从 SSH 会话启动的，而不是从物理控制台启动的。
• 该命令是在没有 nohup和/或的情况下启动的&；然后它被暂停CTRL-Z并在后台恢复bg。
• ssh 会话没有下降。有一个实际的注销 ("exit ”命令）。
• 这个过程是一个 scp文件复制操作。
• 再次登录后，pstree显示进程正在运行并且是init.

编辑 2

更清楚地说明问题：是否将进程置于后台（使用&或bg）使其 ignore SIGHUP，就像nohup命令一样？

编辑 3

我尝试手动发送一个SIGHUPto scp: 它退出了，所以它绝对不会忽略信号。

然后我再次尝试启动它，将它放在后台并注销：它被“采用”init并继续运行，当我重新登录时我在那里找到了它。

我现在很困惑。看起来SIGHUP在注销时根本没有发送。

我最近在 Debian（和 Ubuntu）中发现了“moreutils”包。它是一组方便的 unix 工具。

命令之一是“小便”。手册页说：

小便就像三通，但用于管道。

然而，这是一个简短的手册页，我已经提交了一个关于它的错误。有谁知道它的作用，如何使用它，为什么要使用它？

我的桌面上运行着六个实例，而我管理的服务器上可能运行着十个。这是什么，它对系统功能至关重要吗？

有什么简单的方法可以显示特定 PID 实例的活动时间？

我在 RedHat 盒子上运行 Bacula。有时，存储守护进程 bacula-sd 停止工作并变为<defunct>.

[root@backup ~]# ps -ef | grep defunct | more
root      4801 29261  0 09:25 pts/5    00:00:00 grep defunct
root      5825     1  0 Oct18 ?        00:00:00 [bacula-sd] <defunct>

我的问题是，我怎样才能杀死这个进程？据我所知，它的父级是 1，也就是 init，我不想杀死 init 进程，对吗？

“通常”终止此进程不起作用：

[root@backup ~]# kill -0 5825
[root@backup ~]# kill -9 5825

非常感谢帮助！

编辑：运行

[root@backup ~]# lsof -p 5825

产生以下输出：

COMMAND    PID USER   FD   TYPE  DEVICE     SIZE    NODE NAME
bacula-sd 5825 root  cwd    DIR   253,0     4096 3801089 /root
bacula-sd 5825 root …

这是这个问题的后续。

我还进行了一些测试；看起来这是在物理控制台上完成还是通过 SSH 完成并不重要，这也不仅仅发生在 SCP 上；我也用cat /dev/zero > /dev/null. 行为完全相同：

• 在后台使用启动一个进程&（或者在它开始使用后把它放在后台使用CTRL-Zand bg）；这是在不使用nohup.
• 注销。
• 重新登录。
• 进程还在那里，愉快地运行着，现在是init.

如果发送，我可以确认 SCP 和 CAT 都立即退出SIGHUP；我使用kill -HUP.

因此，看起来 SIGHUP 确实不会在注销时发送，至少不会发送到后台进程（由于显而易见的原因，无法使用前台进程进行测试）。

这发生在我最初使用 VMware ESX 3.5（基于 RedHat）的服务控制台时，但我能够在 CentOS 5.4 上完全复制它。

问题再次出现：是否应该在注销时将 SIGHUP 发送到进程，即使它们在后台运行？为什么这没有发生？

编辑

strace根据凯尔的回答，我检查了。
正如我所期望的那样，从启动它的 shell 注销时，该进程没有收到任何信号。在使用服务器的控制台和通过 SSH 时都会发生这种情况。