Hi Guys,
I am Rupesh currently developing a toolchain to create a syscall profile for Java based docker applications.
I am currently using sysdig to monitor .jar .so and binaries by open,openat,mmap and execve events of a docker container during the startup.
I find that while monitoring the open,openat event to check the .so files opened by java process. I have noticed that the paths for those libraries do not exists
What could be the reason?
Hi @Rupesh, welcome!
Do you mind sharing more details on this? (e.g. running in container )
I can try to reproduce here, based on my experience, it can be something related to the way that JVM works.
hi @edsoncelio
the command i use to capture .jar and .so files during the container restart (ex: in this case its solr:slim).
•sudo sysdig --modern-bpf \ “container.name=$CNAME and evt.type in (open,openat,openat2,mmap) and evt.failed=false and (fd.name contains .so or fd.name contains .jar)” \ -p “%evt.time %evt.type %proc.pid %proc.name %fd.name %fd.typechar” \
Now, i have added a filter evt.failed = false to only record successful events but without that filter I do notice file paths are being recorded which do not exist in the container.
Got it! And it makes sense, for those paths that doesn’t exists you can see something like this right?
14:17:59.287492167 ENOENT openat 5186 java /opt/java/openjdk/lib/aarch64/libjli.so
JVM tries different default search paths for shared libraries, even if the directories or files do not exist inside the container. But from sysdig side is still a openat event, so it’s being recorded, even if it’s not loaded successfully.
My suggestion is to filter by the successful events only, like you’re already doing!
I was guessing the same. Thanks for confirming.
Great! You’re welcome!