1、问题：
通过docker exec产生的进程bash（5704）看ppid是docker-containe（5564），但是通过ptrace进程号5564没有关于clone的系统调用，就算ptrace进程号3594、3542也没有什么有意义的。所以我有一个疑问，这个bash（5704）是由谁产生的？以下通过实验来说明。
2、解决：
利用kprobes中的探测技术kretprobe（基于kprobe实现），探测sys_clone函数的返回值（此返回值为新进程的pid），同时也输出当前进程号
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/kprobes.h>
#include <linux/ktime.h>
#include <linux/limits.h>
#include <linux/sched.h> static char func_name[NAME_MAX] = "sys_clone";
module_param_string(func, func_name, NAME_MAX, S_IRUGO);
MODULE_PARM_DESC(func, "Function to kretprobe; this module will report the"
" function's execution time"); /* per-instance private data */
struct my_data {
ktime_t entry_stamp;
}; /* Here we use the entry_hanlder to timestamp function entry */
static int entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
struct my_data *data; if (!current->mm)
return ; /* Skip kernel threads */ data = (struct my_data *)ri->data;
data->entry_stamp = ktime_get();
return ;
} /*
* Return-probe handler: Log the return value and duration. Duration may turn
* out to be zero consistently, depending upon the granularity of time
* accounting on the platform.
*/
static int ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
int retval = regs_return_value(regs);
struct my_data *data = (struct my_data *)ri->data;
s64 delta;
ktime_t now; now = ktime_get();
delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
printk(KERN_INFO "current task(%d) is %s, %s returned %d and took %lld ns to execute\n",
current->pid, current->comm, func_name, retval, (long long)delta);
return ;
} static struct kretprobe my_kretprobe = {
.handler = ret_handler,
.entry_handler = entry_handler,
.data_size = sizeof(struct my_data),
/* Probe up to 20 instances concurrently. */
.maxactive = ,
}; static int __init kretprobe_init(void)
{
int ret; my_kretprobe.kp.symbol_name = func_name;
ret = register_kretprobe(&my_kretprobe);
if (ret < ) {
printk(KERN_INFO "register_kretprobe failed, returned %d\n",
ret);
return -;
}
printk(KERN_INFO "Planted return probe at %s: %p\n",
my_kretprobe.kp.symbol_name, my_kretprobe.kp.addr);
return ;
} static void __exit kretprobe_exit(void)
{
unregister_kretprobe(&my_kretprobe);
printk(KERN_INFO "kretprobe at %p unregistered\n",
my_kretprobe.kp.addr); /* nmissed > 0 suggests that maxactive was set too low. */
printk(KERN_INFO "Missed probing %d instances of %s\n",
my_kretprobe.nmissed, my_kretprobe.kp.symbol_name);
} module_init(kretprobe_init)
module_exit(kretprobe_exit)
MODULE_LICENSE("GPL");
3、结果
探针输出结果如下：
current task() is docker-containe, sys_clone returned
current task() is docker-containe, sys_clone returned
current task() is docker-containe, sys_clone returned
current task() is docker-containe, sys_clone returned
current task() is docker-containe, sys_clone returned
current task() is docker-containe, sys_clone returned
current task() is docker-containe, sys_clone returned
.......
current task() is docker-containe, sys_clone returned
current task() is docker-runc, sys_clone returned
current task() is docker-runc, sys_clone returned
current task() is docker-runc, sys_clone returned
current task() is docker-runc, sys_clone returned
current task() is docker-runc, sys_clone returned
current task() is docker-runc, sys_clone returned
current task() is runc:[:PARENT], sys_clone returned
current task() is runc:[:CHILD], sys_clone returned
current task() is runc:[:INIT], sys_clone returned
通过pstree -p看到进程树
├─dockerd()─┬─docker-containe()─┬─docker-containe()─┬─bash()
│ │ │ ├─bash()
│ │ │ ├─mysqld()─┬─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ ├─{mysqld}()
│ │ │ │ └─{mysqld}()
│ │ │ ├─{docker-containe}()
│ │ │ ├─{docker-containe}()
│ │ │ ├─{docker-containe}()
│ │ │ ├─{docker-containe}()
│ │ │ ├─{docker-containe}()
│ │ │ ├─{docker-containe}()
│ │ │ ├─{docker-containe}()
│ │ │ └─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ ├─{docker-containe}()
│ │ └─{docker-containe}()
一个图总结，其中红线部分运行完就退出了，所以pstree -p看不到：
所以根本就不是由docker-contained-shim（5564）产生的bash进程，所以ptrace没什么结果。
一个问题：以上红框内runc退出后其子进程bash不是应该由init进程接管吗？如何变成docker-containerd-shim的子进程呢？
解答：从Linux 3.4开始，prctl增加了对PR_SET_CHILD_SUBREAPER的支持，这样就可以控制孤儿进程可以被谁接管，而不是像以前一样只能由init进程接管。
4、后续
左边是strace结果，右边是kret结果。ppid是通过status查看的，可以看到很多不是28323产生的进程，都通过prctl由它接管了
但左边28330显示是parent，而右边显示28330是child
即为：红线内是kret视角（kret一起监控clone和execve，发现parent等的确没有发生execve）
原因猜测：
先clone原进程，新进程刚要运行就会因为被标记的延迟信号（SIGSTOP）要处理，所以第一时间就陷入到strace（strace跟踪多线程与内核的交互），strace此时wait到的pid是新进程的，而name是刚才clone的父进程的。
而后该新进程正常运行，改名（可以通过prctl(PR_SET_NAME, new_name)。参考：linux下修改进程名称），所以该进程发生clone时name和strace看到的已经不同了。
以上是一种根据现象猜测的原因，具体是不是这样需要看docker的在这部分的实现，为啥改名呢？