Bpftrace: Question: why does tracepoint:syscalls:sys_enter_execve print the duplicated messages??

Created on 7 May 2020  路  5Comments  路  Source: iovisor/bpftrace

I'm sorry to bother you.. But I failed to find a user group of bpftrace so that I ask here.
(Actually I found one in reddit, r/bpftrace, but it has only 8 members...)

I am new to bpftrace world.

I use pyenv which manages multiple python installations in a system and it registers some commands to PROMPT_COMMAND variable. Thus whenever I hit a return key at a prompt, some commands related to pyenv are executed.

I monitored execve syscall using this bpftrace one-liner for the first time:

# bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%d ", tid); join(args->argv); }'

But I found it prints so many duplicated lines..
Why is this happening??
The output of bpftrace is attached here: https://pastebin.com/raw/D2LRMez4

I am using Pop!_OS 20.04 and kernel version is 5.4.0-7626-generic.
I built bpftrace from source code, and at the time of building the head commit was cd9ce552c560b43514e2d8525a28d4989683a3b9.

Thanks,

question

All 5 comments

Can you:

  • print the pid
  • print the return value of execve

In this case investigating with set -x might be easier too :)

Hello @fbs
In this time I run this bpf command

bpftrace -e 'tracepoint:syscalls:sys_enter_execve { 
printf("ENTER>>>> %d ", pid); join(args->argv);
} 
tracepoint:syscalls:sys_exit_execve { 
printf ("<<<<EXIT %d %d\n", pid, args->ret);
}'

And the output is here: https://pastebin.com/raw/XHvXyFMv
execve returns -2 several times.. But the man page of it only mentions -1 as an error.. I feel confused 馃槙

And I turned on set -x at other bash prompt and hit the return key. The output is here: https://pastebin.com/raw/iC3hSQXr
But it seems normal.

execve returns -2 several times.. But the man page of it only mentions -1 as an error.. I feel confused 馃槙

Correct, from the glibc manpage:

On success, execve() does not return, on error -1 is returned, and errno is set appropriately.

However, you're not tracing glibc. You're tracing the system call directly. Linux system calls usually return -ERRNO on error and >=0 on success.

In this case it cannot find the binary, so something is probably playing with the path until it works. If you print pid, tid, filename, envp instead you should be seeing what actually is happening.

https://elixir.bootlin.com/linux/v4.20.16/source/include/uapi/asm-generic/errno-base.h#L6

I run this bpftrace one-liner

bpftrace -e 'tracepoint:syscalls:sys_enter_execve { 
printf("ENTER>>>> %d %d %s argv => ", pid, tid, str(args->filename)); join(args->argv); join(args->envp);
} 
tracepoint:syscalls:sys_exit_execve { 
printf ("<<<<EXIT %d %d\n", pid, args->ret);
}'

And the output is here: https://pastebin.com/raw/73BZJywz

As you explained, it seems that -ENOENT is returned from sys_execve repeatedly.
And now I can understand the output more clearly and I became a bit familiar with bpftrace. 馃槃

Thanks,

Cool, closing this one then :)

Was this page helpful?
0 / 5 - 0 ratings