-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to find a process in proc_info_map #3914
Comments
It is reproducible when decreasing
|
yanivagman
added a commit
to yanivagman/tracee
that referenced
this issue
Mar 14, 2024
In environments with a high amount of CPUs the current proc_info map size of 10240 entries might not be enough, and gets filled quickly. In these cases we got an error of missing proc_info entry. A quick mitigation then will be to set a bigger map size. The root cause of this issue is that we assume that if task_info exists for some task in the task_info_map, then also the proc_info of the process to which the task belongs to also has an entry in the map, but that is not the case. To fix this issue, add proc_info lookup and initialization in init_program_data() function. In addition, init proc_info of the relevant pid in case it was not found in other places. Fix: aquasecurity#3914
Merged
yanivagman
added a commit
to yanivagman/tracee
that referenced
this issue
Mar 14, 2024
In environments with a high amount of CPUs the current proc_info map size of 10240 entries might not be enough, and gets filled quickly. In these cases we got an error of missing proc_info entry. A quick mitigation then will be to set a bigger map size. The root cause of this issue is that we assume that if task_info exists for some task in the task_info_map, then also the proc_info of the process to which the task belongs to also has an entry in the map, but that is not the case. To fix this issue, add proc_info lookup and initialization in init_program_data() function. In addition, init proc_info of the relevant pid in case it was not found in other places. Fix: aquasecurity#3914
yanivagman
added a commit
that referenced
this issue
Mar 14, 2024
In environments with a high amount of CPUs the current proc_info map size of 10240 entries might not be enough, and gets filled quickly. In these cases we got an error of missing proc_info entry. A quick mitigation then will be to set a bigger map size. The root cause of this issue is that we assume that if task_info exists for some task in the task_info_map, then also the proc_info of the process to which the task belongs to also has an entry in the map, but that is not the case. To fix this issue, add proc_info lookup and initialization in init_program_data() function. In addition, init proc_info of the relevant pid in case it was not found in other places. Fix: #3914
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
In environments with a big amount of CPUs (96 CPUs) we got the following warnings:
"{"level":"warn","ts":1695678822.5690784,"msg":"Failed to find a map element","id":2,"type":"BPF_LOG_ID_MAP_LOOKUP_ELEM","ret":0,"cpu":82,"file":"./pkg/ebpf/c/tracee.bpf.c","line":603,"count":1}
"{"level":"warn","ts":1710099814.7776074,"msg":"Failed to find a map element","id":2,"type":"BPF_LOG_ID_MAP_LOOKUP_ELEM","ret":0,"cpu":70,"file":"./pkg/ebpf/c/tracee.bpf.c","line":695,"count":1}
These warnings then repeat themselves a lot of times.
Output of
tracee version
:Output of
uname -a
:Additional details
It seems that in such environments the current map size of 10240 entries is not enough, and gets filled quickly.
A quick mitigation then will be to set a bigger map size.
The root cause of this issue is that we assume that if task_info exists for some task in the task_info_map, then also the proc_info of the process to which the task belongs to also has an entry in the map, but that is not the case.
So the real fix to this issue will be to change all the places that try to get an entry from proc_info_map and make this assumption. Instead, we should reinitialize proc_info_t with the matching pid. One problem to implement the reinitialization is that we already lost some of the information like if it was a "new process", the binary name and for which scopes this process should be followed (used by the follow filter).
The text was updated successfully, but these errors were encountered: