如何检测 Linux 上程序的启动？

Question

提问by nub

I wrote a simple daemon. This daemon should respond when I run any program. How to do this? In a big daemon loop:

我写了一个简单的守护进程。当我运行任何程序时，这个守护进程应该响应。这该怎么做？在一个大守护进程循环中：

while(1)
{
   /* function which catches new programm running */
}

What functions to call in linux, when i'm running a new program (create new process)?

当我运行一个新程序（创建新进程）时，在 linux 中调用什么函数？

Answer 1

采纳答案by NPE

I don't know if there exists a better way, but you could periodically scan the /procfilesystem.

我不知道是否有更好的方法，但您可以定期扫描/proc文件系统。

For example, /proc/<pid>/exeis a symlink to the process's executable.

例如，/proc/<pid>/exe是指向进程可执行文件的符号链接。

On my systems (Ubuntu/RedHat), /proc/loadavgcontains the number of running processes (the number after the forward slash) as well as the pid of the most recently started process. If your daemon polls the file, any change to either of the two numbers will tell it when it needs to re-scan /proclooking for new processes.

在我的系统 (Ubuntu/RedHat) 上，/proc/loadavg包含正在运行的进程数（正斜杠后的数字）以及最近启动的进程的 pid。如果您的守护进程轮询文件，对这两个数字中的任何一个进行的任何更改都会告诉它何时需要重新扫描以/proc寻找新进程。

This is by no means bullet-proof, but is the most suitable mechanism I can think of.

这绝不是防弹的，而是我能想到的最合适的机制。

Answer 2

回答by Edwin Buck

You can either scan the operating system for programs that match your criterion or you can wait for a program to report itself to your daemon. Which technique you choose will depend heavily on how much control you have over your non-daemon programs.

您可以扫描操作系统以查找符合您标准的程序，或者您可以等待程序向您的守护程序报告自身。您选择哪种技术将在很大程度上取决于您对非守护程序程序的控制程度。

Scanning can be accomplished by kernel system call, or by reading the user space advertised kernel details (as with the /proc file system). Note that scanning is not a guarantee that you will find any particular program, as if the program manages to launch and terminate between scan cycles, it will not be detected at all.

扫描可以通过内核系统调用来完成，也可以通过读取用户空间公布的内核详细信息（如 /proc 文件系统）来完成。请注意，扫描并不能保证您会找到任何特定程序，就好像该程序设法在扫描周期之间启动和终止一样，它根本不会被检测到。

More complicated techniques of process detection are possible, but they also require more complicated implementations. It is important to know what is truly needed before you start reaching for solutions that are exotic (inserting kernel drivers, etc.), as everything you do is not independent of the system you are monitoring; you actually change the environment by watching it, and some methods of watching the environment might change it inappropriately.

更复杂的进程检测技术是可能的，但它们也需要更复杂的实现。在开始寻找奇异的解决方案（插入内核驱动程序等）之前，了解真正需要什么是很重要的，因为您所做的一切都与您正在监视的系统无关；你实际上是通过观察来改变环境的，而一些观察环境的方法可能会不恰当地改变它。

Answer 3

回答by Chris Stratton

I was interested in trying to figure out how to do this without polling. inotify() does not seem to work on /proc, so that idea is out.

我很想弄清楚如何在没有轮询的情况下做到这一点。inotify() 似乎在 /proc 上不起作用，所以这个想法已经过时了。

However, any program which is dynamically linked is going to access certain files on startup, such as the dynamic linker. This would be useless for security purposes since it won't trigger on a statically linked program, but might still be of interest:

但是，任何动态链接的程序都会在启动时访问某些文件，例如动态链接器。这对于安全目的是无用的，因为它不会在静态链接的程序上触发，但可能仍然令人感兴趣：

#include <stdio.h>
#include <sys/inotify.h>
#include <assert.h>
int main(int argc, char **argv) {
    char buf[256];
    struct inotify_event *event;
    int fd, wd;
    fd=inotify_init();
    assert(fd > -1);
    assert((wd=inotify_add_watch(fd, "/lib/ld-linux.so.2", IN_OPEN)) > 0);
    printf("Watching for events, wd is %x\n", wd);
    while (read(fd, buf, sizeof(buf))) {
      event = (void *) buf;
      printf("watch %d mask %x name(len %d)=\"%s\"\n",
         event->wd, event->mask, event->len, event->name);
    }
    inotify_rm_watch(fd, wd);
    return 0;
}

The events this prints out don't contain any interesting information - the pid of the triggering process doesn't seem to be provided by inotify. However it could be used to wake up and trigger a rescan of /proc

打印出的事件不包含任何有趣的信息 - 触发过程的 pid 似乎不是由 inotify 提供的。但是它可以用来唤醒和触发 /proc 的重新扫描

Also be aware that short-lived programs might vanish again before this thing wakes up and finishes scanning /proc - presumably you would learn that they had existed, but not be able to learn what they were. And of course anybody could just keep opening and closing an fd to the dyanmic linker to drown you in noise.

还要注意，在这件事醒来并完成扫描 /proc 之前，短暂的程序可能会再次消失 - 大概您会知道它们已经存在，但无法了解它们是什么。当然，任何人都可以继续打开和关闭动态链接器的 fd，让您淹没在噪音中。

Answer 4

回答by David Crookes

For Linux, there appears to be an interface in the kernel. Whilst researching this problem I came across people using CONFIG_CONNECTOR and CONFIG_PROC_EVENTS kernel configuration to get events on process death.

对于 Linux，内核中似乎有一个接口。在研究这个问题时，我遇到了使用 CONFIG_CONNECTOR 和 CONFIG_PROC_EVENTS 内核配置来获取进程死亡事件的人。

Some more google and I found this:

更多的谷歌，我发现了这个：

http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/

The Proc Connector and Socket Filters Posted on February 9, 2011 by scott
The proc connector is one of those interesting kernel features that most people rarely come across, and even more rarely find documentation on. Likewise the socket filter. This is a shame, because they're both really quite useful interfaces that might serve a variety of purposes if they were better documented.
The proc connector allows you to receive notification of process events such fork and exec calls, as well as changes to a process's uid, gid or sid (session id). These are provided through a socket-based interface by reading instances of struct proc_event defined in the kernel header....

Proc 连接器和插座过滤器 scott 于 2011 年 2 月 9 日发表
proc 连接器是大多数人很少遇到的有趣的内核特性之一，甚至更难找到相关文档。同样的套接字过滤器。这是一种耻辱，因为它们都是非常有用的接口，如果有更好的文档记录，它们可能会用于各种目的。
proc 连接器允许您接收进程事件的通知，例如 fork 和 exec 调用，以及进程的 uid、gid 或 sid（会话 ID）的更改。这些是通过基于套接字的接口通过读取内核头文件中定义的 struct proc_event 实例提供的。...

The header of interest is:

感兴趣的标题是：

#include <linux/cn_proc.h>

I found example code here:

我在这里找到了示例代码：

http://bewareofgeek.livejournal.com/2945.html

/* This file is licensed under the GPL v2 (http://www.gnu.org/licenses/gpl2.txt) (some parts was originally borrowed from proc events example)

pmon.c

code highlighted with GNU source-highlight 3.1
*/

#define _XOPEN_SOURCE 700
#include <sys/socket.h>
#include <linux/netlink.h>
#include <linux/connector.h>
#include <linux/cn_proc.h>
#include <signal.h>
#include <errno.h>
#include <stdbool.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>

/*
* connect to netlink
* returns netlink socket, or -1 on error
*/
static int nl_connect()
{
int rc;
int nl_sock;
struct sockaddr_nl sa_nl;

nl_sock = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR);
if (nl_sock == -1) {
    perror("socket");
    return -1;
}

sa_nl.nl_family = AF_NETLINK;
sa_nl.nl_groups = CN_IDX_PROC;
sa_nl.nl_pid = getpid();

rc = bind(nl_sock, (struct sockaddr *)&sa_nl, sizeof(sa_nl));
if (rc == -1) {
    perror("bind");
    close(nl_sock);
    return -1;
}

return nl_sock;
}

/*
* subscribe on proc events (process notifications)
*/
static int set_proc_ev_listen(int nl_sock, bool enable)
{
int rc;
struct __attribute__ ((aligned(NLMSG_ALIGNTO))) {
    struct nlmsghdr nl_hdr;
    struct __attribute__ ((__packed__)) {
    struct cn_msg cn_msg;
    enum proc_cn_mcast_op cn_mcast;
    };
} nlcn_msg;

memset(&nlcn_msg, 0, sizeof(nlcn_msg));
nlcn_msg.nl_hdr.nlmsg_len = sizeof(nlcn_msg);
nlcn_msg.nl_hdr.nlmsg_pid = getpid();
nlcn_msg.nl_hdr.nlmsg_type = NLMSG_DONE;

nlcn_msg.cn_msg.id.idx = CN_IDX_PROC;
nlcn_msg.cn_msg.id.val = CN_VAL_PROC;
nlcn_msg.cn_msg.len = sizeof(enum proc_cn_mcast_op);

nlcn_msg.cn_mcast = enable ? PROC_CN_MCAST_LISTEN : PROC_CN_MCAST_IGNORE;

rc = send(nl_sock, &nlcn_msg, sizeof(nlcn_msg), 0);
if (rc == -1) {
    perror("netlink send");
    return -1;
}

return 0;
}

/*
* handle a single process event
*/
static volatile bool need_exit = false;
static int handle_proc_ev(int nl_sock)
{
int rc;
struct __attribute__ ((aligned(NLMSG_ALIGNTO))) {
    struct nlmsghdr nl_hdr;
    struct __attribute__ ((__packed__)) {
    struct cn_msg cn_msg;
    struct proc_event proc_ev;
    };
} nlcn_msg;

while (!need_exit) {
    rc = recv(nl_sock, &nlcn_msg, sizeof(nlcn_msg), 0);
    if (rc == 0) {
    /* shutdown? */
    return 0;
    } else if (rc == -1) {
    if (errno == EINTR) continue;
    perror("netlink recv");
    return -1;
    }
    switch (nlcn_msg.proc_ev.what) {
    case PROC_EVENT_NONE:
        printf("set mcast listen ok\n");
        break;
    case PROC_EVENT_FORK:
        printf("fork: parent tid=%d pid=%d -> child tid=%d pid=%d\n",
            nlcn_msg.proc_ev.event_data.fork.parent_pid,
            nlcn_msg.proc_ev.event_data.fork.parent_tgid,
            nlcn_msg.proc_ev.event_data.fork.child_pid,
            nlcn_msg.proc_ev.event_data.fork.child_tgid);
        break;
    case PROC_EVENT_EXEC:
        printf("exec: tid=%d pid=%d\n",
            nlcn_msg.proc_ev.event_data.exec.process_pid,
            nlcn_msg.proc_ev.event_data.exec.process_tgid);
        break;
    case PROC_EVENT_UID:
        printf("uid change: tid=%d pid=%d from %d to %d\n",
            nlcn_msg.proc_ev.event_data.id.process_pid,
            nlcn_msg.proc_ev.event_data.id.process_tgid,
            nlcn_msg.proc_ev.event_data.id.r.ruid,
            nlcn_msg.proc_ev.event_data.id.e.euid);
        break;
    case PROC_EVENT_GID:
        printf("gid change: tid=%d pid=%d from %d to %d\n",
            nlcn_msg.proc_ev.event_data.id.process_pid,
            nlcn_msg.proc_ev.event_data.id.process_tgid,
            nlcn_msg.proc_ev.event_data.id.r.rgid,
            nlcn_msg.proc_ev.event_data.id.e.egid);
        break;
    case PROC_EVENT_EXIT:
        printf("exit: tid=%d pid=%d exit_code=%d\n",
            nlcn_msg.proc_ev.event_data.exit.process_pid,
            nlcn_msg.proc_ev.event_data.exit.process_tgid,
            nlcn_msg.proc_ev.event_data.exit.exit_code);
        break;
    default:
        printf("unhandled proc event\n");
        break;
    }
}

return 0;
}

static void on_sigint(int unused)
{
need_exit = true;
}

int main(int argc, const char *argv[])
{
int nl_sock;
int rc = EXIT_SUCCESS;

signal(SIGINT, &on_sigint);
siginterrupt(SIGINT, true);

nl_sock = nl_connect();
if (nl_sock == -1)
    exit(EXIT_FAILURE);

rc = set_proc_ev_listen(nl_sock, true);
if (rc == -1) {
    rc = EXIT_FAILURE;
    goto out;
}

rc = handle_proc_ev(nl_sock);
if (rc == -1) {
    rc = EXIT_FAILURE;
    goto out;
}

    set_proc_ev_listen(nl_sock, false);

out:
close(nl_sock);
exit(rc);
}

I found that this code needs to run as root to get the notifications.

我发现此代码需要以 root 身份运行才能获取通知。

Answer 5

回答by Arnaud Meuret

Have a look at this little programby Sebastian Krahmer it does exactly what you are asking in a resource efficient way and pretty simple code.

看看Sebastian Krahmer 的这个小程序，它以资源高效的方式和非常简单的代码完全满足您的要求。

It does require that your kernel has CONFIG_PROC_EVENTS enabled, which is not the case on the latest Amazon Linux Image (2012.09) for example.

它确实需要您的内核启用 CONFIG_PROC_EVENTS，例如，最新的 Amazon Linux Image (2012.09) 并非如此。

UPDATE: Following a request to Amazonthe Amazon Linux Image kernels now support PROC_EVENTS

更新：应亚马逊的请求，亚马逊 Linux 映像内核现在支持 PROC_EVENTS

Answer 6

回答by Tobu

Use forkstat, it's the most complete client for proc events:

使用forkstat，它是 proc 事件最完整的客户端：

sudo forkstat -e exec,comm,core

GitWeb：http://kernel.ubuntu.com/git?p=cking/forkstat.git
公告：http: //smackerelofopinion.blogspot.com/2014/03/forkstat-new-tool-to-trace-process.html

Packaged in Ubuntu, Debian and the AUR.

打包在 Ubuntu、Debian 和 AUR 中。

Before that, there was cn_proc:

在此之前，有cn_proc：

 bzr branch lp:~kees/+junk/cn_proc

The Makefile needs a small change (LDLIBSinstead of LDFLAGS).

Makefile 需要一个小的更改（LDLIBS而不是LDFLAGS）。

cn_proc and exec-notify.c(which Arnaud posted) share a common ancestor; cn_proc handles a few more events and has cleaner output, but isn't resilient when processes exit quickly.

cn_proc 和exec-notify.c（由 Arnaud 发布）共享一个共同的祖先；cn_proc 处理更多事件并具有更清晰的输出，但在进程快速退出时没有弹性。

Ooh, found another fork of exec-notify, extrace. This one indents child processes below their parent (using a pid_depth heuristic).

哦，找到了另一个 exec-notify，extrace 的分支。这个缩进子进程低于其父进程（使用 pid_depth 启发式）。

Answer 7

回答by Ikem Krueger

The keyword for the search machine of your choice is "process event connector".

您选择的搜索机器的关键字是“过程事件连接器”。

I found two tools that utilize them, exec-notifyand cn_proc.

我找到了两个使用它们的工具，exec-notify和cn_proc。

I like the later more, but both do their jobs very well.

我更喜欢后者，但两者都做得很好。

如何检测 Linux 上程序的启动？

提问by nub

采纳答案by NPE

回答by Edwin Buck

回答by Chris Stratton

回答by David Crookes

回答by Arnaud Meuret

回答by Tobu

回答by Ikem Krueger

相关推荐

最近更新

标签

如何检测 Linux 上程序的启动？

提问by nub

采纳答案by NPE

回答by Edwin Buck

回答by Chris Stratton

回答by David Crookes

回答by Arnaud Meuret

回答by Tobu

回答by Ikem Krueger

相关推荐

Linux 执行默认信号处理程序

Linux 如何在python中获取格式化的日期时间

C# 位图与 OnPaintBackground 中的 TextRenderer.DrawText

Linux 如何分配线程本地存储？

相关推荐

最近更新

标签