如何确定进程的状态(即是否为僵尸进程)
如何在 Linux 下使用 C 获取有关进程状态的信息(即是否为僵尸进程)?
阅读到目前为止的答案后,我想稍微缩小我的问题:我更喜欢纯 C 解决方案。 阅读 ps 源代码(读取 /proc/)后,我认为应该有更好的方法并在这里询问:)
how can I get information on the state of a process (i.e. if it is a zombie) using C under Linux?
After reading the answers so far I want to narrow my question somewhat: I would prefer a pure C solution. After reading the ps source (which reads /proc/) I thought that there should be a better way and asked here :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
您将需要了解如何通过典型的 C 标准库调用与 /proc/“psuedo-filesystem”进行交互。 任何 Linux 发行版都包含入门所需的文档,只需通过 google 搜索即可。
(现在您知道要搜索什么了。我知道这通常是最大的挑战!)
简而言之,正在运行的 Linux 系统的 /proc/ 目录中的目录和文件反映了正在运行的内核的状态,这(自然)包括流程。 但是,在充电之前,您需要记住一些信息。
僵尸进程与孤立进程不同。 孤立进程是指在其父进程错误退出后仍处于等待状态的进程。 僵尸进程是已正确退出、释放其所有资源、但仍在进程表中保留一席之地的进程。
这通常发生在程序启动进程时。 您会看到,在父程序正确获取子进程的返回状态之前,内核不会删除进程表中已完成的子进程的条目。 这就说得通了; 父程序如何知道子进程是否异常退出?
因此,从技术上讲,所有子进程至少在很短的时间内都是僵尸进程。 对于程序来说,这本质上并不是一个坏的状态。
事实上,“僵尸”有时是故意创建的。 例如,有时程序会将僵尸条目保留一段时间,以便进一步启动的进程不会获得与先前启动的(现在是僵尸)进程相同的 PID。
换句话说,如果不必要地对僵尸进程发出 SIGCHLD,则可能会给生成程序带来严重的问题。 但是,如果一个进程处于僵尸状态半小时或更长时间,则可能是存在错误的迹象。
编辑:问题对我来说改变了! 不,没有比 ps 更简单的方法了。 如果有的话,早就集成到ps里了。 /proc 文件是有关内核状态信息的最终来源。 :)
You'll want to learn about interacting with the /proc/ "psuedo-filesystem" via typical C standard library calls. The documentation necessary to get started is included with any Linux distro and is a simple google search away.
(Now that you know what to search for. I know that's usually most of the challenge!)
In short, the directories and files within the /proc/ directory of a running Linux system reflect the state of the running kernel, which (naturally) includes processes. However, before you charge in you need to keep some information in mind.
A zombie process isn't the same thing as an orphaned process. An orphaned process is a process left running in a waiting state after the process' parent has exited incorrectly. A zombie process is a process which has exited properly, released all its resources, but is maintaining a place in the process table.
This typically happens when a process is launched by a program. You see, the kernel won't remove a finished sub-process' entry in the process table until the parent program properly fetches the return status of the sub-process. That makes sense; how else would the parent program know if the subprocess exited improperly?
So all subprocesses are technically zombies for at least a very short time. It's not inherently a bad state for a program to be in.
Indeed, "zombies" are sometimes created intentionally. For example, sometimes a zombie entry is left in place by a program for a while so that further launched processes won't get the same PID as the previously-launched (and now zombie) process.
In other words, if you go SIGCHLDing zombie processes unnecessarily you might create a serious problem for the spawning program. However, if a process has been a zombie for a half hour or more, it's probably a sign of a bug.
Edit: The question changed on me! No, there's no simpler way than how ps does it. If there was, it would have been integrated into ps a long time ago. The /proc files are the be-all-end-all source for information on the kernel's state. :)
我只知道两种方法:
I know only two ways:
ps
commandps
does internally)您希望进程在您的计算机上运行,然后使用
$ ps aux
ps 显示有关选定的活动进程的信息。 如果您想要重复更新选择和显示的信息,请改用top。
You want the processes running on your machine then use
$ ps aux
ps displays information about a selection of the active processes. If you want a repetitive update of the selection and the displayed information, use top instead.
伪文件系统 /proc 描述内核内部数据结构,并为您提供直接更改某些值的机会。
使用 I/OC 函数可以轻松实现获取特定进程的状态。 正确解析的文件是: /proc/{PID}/status
下面的命令可用于获取僵尸状态的进程。
Pseudo file system /proc is describing kernel internal data structures and gives to you opportunity to alter some values directly.
Obtaining state of particular process can be easily implemented with I/O C functions. The right file to parse is: /proc/{PID}/status
Command below can be used to obtain processes in Zombie state.
找到此处:
这可以使用 C 轻松解析。
Found here:
This could be easily parsed using C.