Skip to content
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

Closed
wants to merge 2 commits into from
Closed

Disable core dumps for workspaces #12814

wants to merge 2 commits into from

Conversation

Furisto
Copy link
Member

@Furisto Furisto commented Sep 9, 2022

Description

Disable core dumps for workspaces

Related Issue(s)

Fixes #12453

How to test

  • Open workspace
  • sleep 900&
  • kill -s SIGSEGV [pid]

Release Notes

Prevent core dumps from cluttering workspaces

Documentation

Werft options:

  • /werft with-preview

@Furisto Furisto force-pushed the fo/disable-core-dumps branch from 4fc9413 to 28ecfce Compare September 9, 2022 10:57
@roboquat roboquat added size/S and removed size/XS labels Sep 9, 2022
@Furisto Furisto force-pushed the fo/disable-core-dumps branch from 19031a9 to 28ecfce Compare September 9, 2022 12:05
@roboquat roboquat added size/XS and removed size/S labels Sep 9, 2022
@Furisto
Copy link
Member Author

Furisto commented Sep 19, 2022

@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?

@david-bakin
Copy link

david-bakin commented Sep 19, 2022

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 .gitpod.yml, or, possibly, via gp for the duration of the workspace (or of one open session of the workspace).


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".

@Furisto
Copy link
Member Author

Furisto commented Sep 20, 2022

@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.

@utam0k
Copy link
Contributor

utam0k commented Sep 21, 2022

@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?

My first impression is a lack of capability. We need CAP_SYS_PTRACE to run strace.

@csweichel
Copy link
Contributor

We definitely would like to preserve that ability.

What stops users from re-starting their workspace with the corresponding .gitpod.yml change?

@aledbf aledbf closed this Sep 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Workspace Cluttered with core.* files
6 participants