-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Disable core dumps for workspaces #12814
Conversation
4fc9413
to
28ecfce
Compare
19031a9
to
28ecfce
Compare
@utam0k This prevents core dumps from being created but it also means that the user is not allowed to change the core limit anymore with prlimit or ulimit (due to operation not permitted error) in case he actually wants to create a core dump for debugging purposes. I have allowed prlimit64 and setrlimit in the seccomp profile (strace shows that both tools are using prlimit64) but this did not have any effect. Do you have any idea why what the problem could be? |
Am I understanding @Furisto 's comment above correctly: I can't get coredumps now at all? If so: 👎 👎 👎 This commit doesn't even distinguish between core dumps created during start tasks and core dumps created when the user is actively doing development in the workspace. This cannot be an acceptable outcome of this PR. How is one supposed to do any work† in C++ and other languages (Rust, possibly Go, possibly Python when debugging C++ addins)? Core dumps are a problem in Gitpod (see #13102) but there must be a way to allow them, even if not by default. (And that way should be documented properly too.) Please consider instead a proper user-oriented solution to the problem of annoying/troublesome core dump files. See, e.g., the discussion at #13102. If you absolutely must do this then it really really really needs an attribute to override it, settable in workspace's † Yes, an exaggeration. One can still do a lot of work in C++ without core dump files. But not everything. Sometimes they're essential. Completely disallowing core dump files in use cases where they're essential is certainly not "development without friction". |
@david-bakin Sorry if that was not clear from my comment above, but users not being able to reenable core dumps if they require it for development is precisely the reason this PR is still in draft form. We definitely would like to preserve that ability. |
4826de8
to
1c653ff
Compare
My first impression is a lack of capability. We need |
What stops users from re-starting their workspace with the corresponding |
Description
Disable core dumps for workspaces
Related Issue(s)
Fixes #12453
How to test
sleep 900&
kill -s SIGSEGV [pid]
Release Notes
Documentation
Werft options: