Comments (13)
cc @leogr
from sysdig.
@dkogan I was able to reproduce the issue you raised when installing sysdig from a fresh debian:sid
container, in which it comes with the 0.35.0+repack
version. Let me respond point by point to provide context.
This tag exists in git. To any outside observer, it looks as official as any other. If this was intended to be a pre-release, can you call it "0.35.0rc1", or something?
Totally agree with this, it was a mistake on our end. We created the tag and kept the GitHub release on hold in order to wait for the Falco 0.37 release (the two are aligned in the version of falcosecurity/libs they
depend to). We'll proceed in finishing the 0.35 sysdig release and we'll pay extra attention in the future, apologies.
I haven't tried it myself, but I was pretty sure that this isn't broken with whatever "normal" build you're normally doing.
It really works on our end, and there is a reason behind it. During the contribution process of the falcosecurity/libs
to the CNCF, we prioritized making them as vendor agnostic as possible even at the codebase level. This affected the code in some ways, and the CMake setup as well. For example, the default name for the kernel drivers is now scap.ko
but it's now possible to customize it through CMake variables so that each adopter can have degrees of freedom for their product or use cases.
The core implementation of chisels lives in falcosecurity/libs
, and have been affected by these changes too. The sysdig.*
functionalities are a way of accessing some core functions of the tool running the chisel, and given that the code for that resides in libsinsp (a component of the falcosecurity libs), the default name has been set as sinsp.*
and we allow each client or adopter to customize it (https://github.com/falcosecurity/libs/blob/93a04bb92f85142edbfb47120cbaafb45d9ba5d8/userspace/libsinsp/CMakeLists.txt#L32). For the case of sysdig tool, this is still available as sysdig.*
(we didn't want to introduce any breaking change) and the custom name is set through cmake (
Now, I think the problem here is straightforward. For packages provides by us, this works as expected because we build both sysdig and the libraries together. In your case, I think this is broken because you build the libs as a standalone library and then link it to sysdig afterwards, thus picking up the sinsp.*
default name. I can confirm that by substituting every sysdig.*
with a sinsp.*
in the udp_extract
chisel of your example, everything keeps working as expected.
Next steps
The issue here is on our end, because your use case is completely legitimate, and rather more appropriate than what we do. We're now looking for a clean way of solving this, and will get back at you once done. We will for sure issue a new release of sysdig once done. For now, we'll proceed in publishing the GitHub release for 0.35.0 like mentioned above.
cc @leogr, @mrgian, @therealbobo
from sysdig.
In Debian today, falcosecurity/libs and sysdig are the only two components that touch these chisels. So for these packages, I can set CHISEL_TOOL_LIBRARY_NAME="sysdig" when building falcosecurity-libs. Is there any reason not to do that?
If that's possible to do on your end, then I think this is the best workaround available for now! Let me know if you encounter problems with that.
On the long run, I think this approach will not be the best once other packages will start rely on the falcosecurity-libs, which for example could be the case of Falco somewhere in the future. On our side, we'll keep looking into a solution that would be more sustainable. Thanks!
About 0.35.0: the tag was made and there's a Debian package of this uploaded, so it has been "released", even if it wasn't finished. When you do finish it, can you call it "0.35.1"?
Yeah, what I meant is to remove the "draft" status from the GitHub release too, to communicate that the 0.35.0 release actually happened and keeping the same tag as the one of the Debian packages.
from sysdig.
@dkogan giving you the update that since v0.36.1 (https://github.com/draios/sysdig/releases/tag/0.36.1), @therealbobo worked on moving/forking code for chisels from falcosecurity/libs to become an internal component of the sysdic codebase. This means that the issue reported above would be solved, starting from that version, without any extra workaround.
from sysdig.
@dkogan thanks for reporting. Did you find the minimum sysdig version in which this is reproduced?
from sysdig.
Hi. I haven't tried bisecting this. It's such a fundamental problem, that I think it should be trivial to debug for those that have internal familiarity with the code. Let me know if you have trouble reproducing.
from sysdig.
We tested this with sysdig 0.35.0 but we weren't able to reproduce this
Can you provide the OS version you've tested this?
I'm looking forward to figure out the version of the dependencies you are building this with.
from sysdig.
Hi. The packages in Debian/sid and Debian/bookworm (the current stable release) are affected. Ubuntu/jammy is probably affected; I would have to check. The next Ubuntu release (24.04) will pull from whatever is in Debian/sid today, so it would be affected as well, if this isn't fixed.
What did you test, exactly? There is no "0.35.0" package.
I can also debug this myself, if you point me at things I should look at.
Thanks
from sysdig.
Hi @dkogan. We have a 0.35.0 tag that is still under a release draft (not official), and we tested the same exact command you posted. We thought about using this git tag due to your sentence above The current packaged release is of 0.35.0, but this issue isn't new in 0.35
, which made us think that you used it too. We haven't experienced the bug you posted, however our build was using the bundled dependencies and not the system one. So for now our suspect is that there should be some difference when using the system deps, as we could not find anything suspicious by looking at the code either (which has been barely touched in the past months).
from sysdig.
from sysdig.
Hi @dkogan
I've tried with a fresh install of Debian bookworm by pulling the package from the official repos,
but unfortunately I'm still not able to reproduce this issue.
Can you provide the versions of lua
and liblua
you are using?
Thank you
from sysdig.
Hi. Sorry about claiming bookworm was affected; I thought it was. And it's great that you could reproduce the problem.
About 0.35.0: the tag was made and there's a Debian package of this uploaded, so it has been "released", even if it wasn't finished. When you do finish it, can you call it "0.35.1"?
Thank you very much for debugging. In Debian today, falcosecurity/libs and sysdig are the only two components that touch these chisels. So for these packages, I can set CHISEL_TOOL_LIBRARY_NAME="sysdig" when building falcosecurity-libs. Is there any reason not to do that?
from sysdig.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
from sysdig.
Related Issues (20)
- csysdig Crashes When `~/chisels` Directory Is Missing HOT 11
- Ask about evt.type=procinfo HOT 3
- UDP connections not closing anymore HOT 1
- implicit declaration of function 'strlcpy'; did you mean 'strscpy'? HOT 3
- Trash in images HOT 4
- Issue with Terraform Provider HOT 1
- Question: Implications of chisles removal from falcosecurity/libs HOT 2
- Max size of --snaplen HOT 1
- 0.36.1 build failure HOT 1
- Error! Bad return status for module build on kernel: 6.8.7-arch1-2 (x86_64) HOT 2
- error linking to falcosecurity-libs built as a shared library HOT 2
- Use --modern-bpf as a fallback when /dev/scap0 does not exist?
- Sign Sysdig modules to support running on systems with Secure Boot enabled
- [*] Can't find "%proc.exe_ino" in output file HOT 1
- Building sysdig fails with userspace/libscap/engine/kmod/scap_kmod.c:372:(.text+0x35c7): undefined reference to `scap_get_host_root' HOT 3
- Possibility of LXD container support HOT 1
- monitor interface operation
- I want to use “-pk” and "k8s.pod.name" filter option,now I need install what libs?
- the event information captured by sysdig is incomplete,and the evt.num is not consecutive? HOT 1
- Cant install sysdig on RedHat 9.4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sysdig.