On Sun, Aug 11, 2019 at 11:21 AM Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> wrote: > > On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote: > > I don't follow. You're saying RelWithDebInfo is never suitable for a > > local build? > > Most of the time. What is your use case for it? My use case is testing the responsiveness of Fedora Workstation under CPU and memory pressure, as experienced by an ordinary user. > > In file included from Source/JavaScriptCore/config.h:32, > > from Source/JavaScriptCore/llint/LLIntSettingsExtractor.cpp:26: > > Source/JavaScriptCore/runtime/JSExportMacros.h:32:10: fatal error: wtf/ExportMacros.h: No such file or directory > > You are reinventing the wheel Fedora packager has already done for this > package. That's out of scope. I said from the outset this is an example. The central topic is that an unprivileged program is able to ask for resources that do not exist, and the operating system tries and fails to supply those resources, resulting not only in task failure, but the entire system is lost. In this example the user is doing other things concurrently and likely experiences data loss and possibly even file system corruption as a direct consequence of having to force power off on the machine because for all practical purposes normal control has been lost. > > Let's take another argument. If the user manually specifies 'ninja -j > > 64' on this same system, is that sabotage? > > For untrusted users Linux has given up for that, it is too big can of worms. > Use virtual machine (KVM) with specified resources (memory size). Nowadays it > should be also possible with less overhead by using Docker containers. > > If you mean some local builds of your own causing runaway then > (1) Turn off swap as RAM is cheap enough today. > If something really runs out of the RAM it gets killed by kernel OOM. > (2) Have the swap on NVMe, it from my experience does not kill the machine. > (3) Use some reasonable ulimits in your ~/.bash_profile. > (4) When the machine is really unresponsible login there from a different box > and kill the culprits. From my own experience the machine is still able to > accept new SSH connection, despite a bit slowly. > But yes, I agree this problem has AFAIK no perfect solution. I don't think it's acceptable in 2019 that an unpriviledged task takes out the entire operating system. As I mention in the very first post, remote ssh was not responsive for 30 minutes, at which point I gave up and forced power off. It's a bit of a trap though to suggest the user needs the ability and skill to remote ssh to kill off runaway programs, I refuse that premise. It's completely sane for an ordinary user to consider that control of the system has been lost immediately upon experiencing a frozen mouse arrow. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
