You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When capturing packets with tracee, multiple error messages appear:
$ sudo dist/tracee -c network -c pcap:command 2>&1 | grep error
{"level":"error","ts":1716287449.0487154,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
{"level":"error","ts":1716287449.0491126,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
{"level":"error","ts":1716287454.4983273,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
{"level":"error","ts":1716287454.4984045,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
Printing the file paths that fail to open, we see the following:
What happens is that the process is a kernel thread and its name contains a slash which interferes with the file path. Not checking the process names for characters that are illegal in file names is an issue, but we shouldn't be receiving packets from kernel threads regardless.
Selecting the network events which the packets are derived from, we can see there's an issue:
We are getting a network event from the swapper/6 kernel thread, which seems to share a host PID and host TID with the node process, but the rest of the context is different.
This may be a symptom of the changes made in f806cb4 and a fix to an issue they caused in #3949.
Description
When capturing packets with tracee, multiple error messages appear:
Printing the file paths that fail to open, we see the following:
What happens is that the process is a kernel thread and its name contains a slash which interferes with the file path. Not checking the process names for characters that are illegal in file names is an issue, but we shouldn't be receiving packets from kernel threads regardless.
Selecting the network events which the packets are derived from, we can see there's an issue:
We are getting a network event from the swapper/6 kernel thread, which seems to share a host PID and host TID with the node process, but the rest of the context is different.
This may be a symptom of the changes made in f806cb4 and a fix to an issue they caused in #3949.
Output of
tracee version
:Output of
uname -a
:The text was updated successfully, but these errors were encountered: