【问题标题】:How to detect the launching of programs on Linux?如何检测 Linux 上程序的启动?
【发布时间】:2011-08-29 19:42:54
【问题描述】:

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

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

当我运行一个新程序(创建新进程)时,在 linux 中调用什么函数?

【问题讨论】:

  • 我认为我们需要更多信息
  • @Adam Batkin - 我不同意,这个问题已经充分说明,发布者希望在流程创建时得到通知
  • 这个守护进程是在启动 firefox 还是由用户从外部启动 firefox 并且您希望收到通知?您的问题需要澄清一下。
  • @Chris:这当然是一个有效的解释。随意编辑问题以使其更清楚
  • audit daemon 可以通过跟踪 execve 系统调用来 log the programs that are run。也许你能从中得到启发。

标签: c linux pid


【解决方案1】:

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

更多谷歌,我发现了这个:

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

Proc 连接器和套接字过滤器 斯科特发表于 2011 年 2 月 9 日

proc 连接器是大多数人很少遇到的有趣的内核功能之一,甚至很少会在其中找到文档。插座过滤器也是如此。真可惜,因为它们都是非常有用的接口,如果有更好的文档记录,它们可能会用于多种用途。

proc 连接器允许您接收进程事件的通知,例如 fork 和 exec 调用,以及对进程的 uid、gid 或 sid(会话 id)的更改。这些是通过基于套接字的接口通过读取内核头文件中定义的 struct proc_event 实例来提供的......

感兴趣的标题是:

#include <linux/cn_proc.h>

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

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);
}

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

【讨论】:

  • 出色的一个 - 帮助为 superuser.com/questions/354150/… 创建解决方案 ;-)
  • 这很漂亮,开始认为我将不得不深入内核代码......
  • 请注意,如果需要,您可以使用衍生进程的 pid 从 /proc/ 目录读取其他进程信息。我用它来提取命令行信息,以便在创建时也显示进程的名称。
【解决方案2】:

我很想弄清楚如何在不进行轮询的情况下做到这一点。 inotify() 似乎不适用于 /proc,所以这个想法已经过时了。

但是,任何动态链接的程序都会在启动时访问某些文件,例如动态链接器。出于安全目的,这将无用,因为它不会在静态链接的程序上触发,但可能仍然值得关注:

#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;
}

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

另外请注意,短暂的程序可能会在这个东西醒来并完成扫描 /proc 之前再次消失 - 大概你会知道它们已经存在,但无法知道它们是什么。当然,任何人都可以不停地打开和关闭动态链接器的 fd,让你沉浸在噪音中。

【讨论】:

    【解决方案3】:

    使用forkstat,它是最完整的proc事件客户端:

    sudo forkstat -e exec,comm,core
    

    打包在 Ubuntu、Debian 和 AUR 中。


    在此之前,有cn_proc

     bzr branch lp:~kees/+junk/cn_proc
    

    Makefile 需要稍作改动(LDLIBS 而不是 LDFLAGS)。

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


    哦,找到了另一个 exec-notify 分支,extrace。 这将子进程缩进到父进程之下(使用 pid_depth 启发式)。

    【讨论】:

    • Debian 和 Ubuntu apt 软件包:forkstatextrace。顺便说一句:由于某种原因,这两个工具在我基于 WSL2 的 Ubuntu 20.04 LTS 中都不起作用,它们不会收到任何进程创建的通知。
    【解决方案4】:

    看看 Sebastian Krahmer 的 this little program,它以一种资源高效的方式和非常简单的代码完全符合您的要求。

    它确实需要您的内核启用 CONFIG_PROC_EVENTS,例如,最新的 Amazon Linux Image (2012.09) 就不是这种情况。

    更新:继 request to Amazon 之后,Amazon Linux 映像内核现在支持 PROC_EVENTS

    【讨论】:

    【解决方案5】:

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

    我找到了两个使用它们的工具,exec-notifycn_proc

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

    【讨论】:

      【解决方案6】:

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

      例如,/proc/&lt;pid&gt;/exe 是指向进程可执行文件的符号链接。

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

      这绝不是万无一失的,但却是我能想到的最合适的机制。

      【讨论】:

      • 谢谢! /proc/loadavg 真的很好。但是如何将信息添加到 /proc/loadavg 中?
      • @nub:我提议将/proc/loadavg 作为通知机制(必须进行轮询)。除了某些事情发生了变化之外,它不会告诉您任何事情。要弄清楚发生了什么变化,您需要扫描/proc/[0-9]*
      • 是的,但是new pid的信息是怎么得到的呢?因为首先获取这些信息(如何?),然后推送到 /proc/loadavg。
      • /proc/loadavg 是内核导出的一种假文件。当您尝试读取它时,您会直接从内核中获取信息。
      • 您可能会错过两次扫描之间的数十个进程的启动和终止,以及进程启动和终止时什么都没有发生的事情。
      【解决方案7】:

      您可以扫描操作系统以查找符合您的条件的程序,也可以等待程序向您的守护程序报告自身。您选择哪种技术很大程度上取决于您对非守护程序的控制程度。

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

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

      【讨论】:

        【解决方案8】:

        CONFIG_FTRACECONFIG_KPROBESbrendangregg/perf-tools

        git clone https://github.com/brendangregg/perf-tools.git
        cd perf-tools
        git checkout 98d42a2a1493d2d1c651a5c396e015d4f082eb20
        sudo ./execsnoop
        

        在另一个外壳上:

        while true; do sleep 1; date; done
        

        第一个shell显示格式的数据:

        Tracing exec()s. Ctrl-C to end.                                                        
        Instrumenting sys_execve                                                               
           PID   PPID ARGS 
         20109   4336 date                                                                                       
         20110   4336 sleep 1                                                                                    
         20111   4336 date                                                                                                                                                                                                 
         20112   4336 sleep 1                                                                                    
         20113   4336 date                                                                                       
         20114   4336 sleep 1                                                                                    
         20115   4336 date                                                                                       
         20116   4336 sleep 1
        

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2013-10-18
          • 1970-01-01
          • 1970-01-01
          • 2016-02-23
          • 1970-01-01
          相关资源
          最近更新 更多