this post was submitted on 31 Oct 2024
437 points (92.9% liked)

linuxmemes

21172 readers
1405 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     

    Seen on the FOSS Weekly #24.44: https://itsfoss.com/newsletter/foss-weekly-24-44/

    all 46 comments
    sorted by: hot top controversial new old
    [–] cypherpunks@lemmy.ml 31 points 3 days ago (3 children)

    I'm not sure what this comic is trying to say but in my recent experience a single misbehaving website can still consume all available swap at which point Linux will sometimes completely lock up for many minutes before the out-of-memory killer decides what to kill - and then sometimes it still kills the desktop environment instead of the browser.

    (I do know how to use oom_adj; I'm talking about the default configuration on popular desktop distros.)

    [–] kolorafa@lemmy.world 0 points 1 day ago* (last edited 1 day ago)

    Linux is slow at killing apps when you run out of memory because it was designed to also run on low spec hardware even if very slowly (making the ui totally unrensposnive) due to swapping.

    This comic is about the kill command, how Linux kernel is handling force stopping apps vs (old?) Windows when if App frozed it was hard to close it. Now with modern apps and hardware you very rarely see that as most apps are designed to have asynchronous logic that is correctly handled, but it's still more or less relevant.

    [–] MonkderVierte@lemmy.ml 5 points 3 days ago

    Yeah, OOM not being aggressive enough (i.e. not triggering at all) is an age old issue. There's earlyoom or nohang for this, further ressources in the description.

    [–] QuazarOmega@lemy.lol 2 points 3 days ago (1 children)

    Real, happened too many times to me. What's that about configuring the OOM, can you give it priorities?

    [–] cypherpunks@lemmy.ml 4 points 3 days ago* (last edited 3 days ago) (1 children)

    The canonical documentation is https://www.kernel.org/doc/Documentation/filesystems/proc.rst (ctrl-f oom) but if you search a bit you'll find various guides that might be easier to digest.

    https://www.baeldung.com/linux/memory-overcommitment-oom-killer looks like an informative recent article on the subject, and reminds me that my knowledge is a bit outdated. (TIL about the choom(1) command which was added to util-linux in 2018 as an alternative to manipulating things in /proc directly...)

    https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9 from 2018 might also be worth reading.

    How to make your adjustments persist for a given desktop application is left as an exercise to the reader :)

    [–] QuazarOmega@lemy.lol 2 points 3 days ago

    Thanks! Will have to come back to this

    [–] Rin@lemm.ee 5 points 2 days ago

    I'm so thankful for the OOM killer for saving my system when i do dumb shit

    [–] nailbar@sopuli.xyz 18 points 3 days ago

    I recently had some processes lock up on Linux, and after searching what the "D" symbol in ps aux was (Uninterruptable sleep), i found this little line:

    The only non-sophisticated way to get rid of them is to reboot the system

    [–] gravitas_deficiency@sh.itjust.works 58 points 4 days ago (2 children)
    [–] possiblylinux127@lemmy.zip 20 points 4 days ago (3 children)

    You really shouldn't do that. You risk leaving behind children and locks

    [–] gravitas_deficiency@sh.itjust.works 46 points 4 days ago (1 children)

    Hey man, I’ve got a hammer, and that process looks a lot like a nail.

    [–] possiblylinux127@lemmy.zip 3 points 4 days ago

    The process looks like a buggy application

    [–] muntedcrocodile@lemm.ee 5 points 4 days ago

    When ive tried asking nicely ima call up my friend sudo.

    [–] user224@lemmy.sdf.org 4 points 4 days ago

    Damn kids these days.

    [–] UtMan1988@lemmy.world 1 points 3 days ago

    kill -15

    Terminate normally if possible.

    [–] possiblylinux127@lemmy.zip 47 points 4 days ago (3 children)
    taskill /F /IM app.exe
    

    There you go

    [–] phoenixz@lemmy.ca 11 points 4 days ago

    Nah, CTRL SHIFT ESC ... Click and it's gone

    [–] systemglitch@lemmy.world 8 points 4 days ago (1 children)

    I feel like it's easy enough to kill on windoes as well. Windows is down to about once every two years where it completely hangs.

    [–] possiblylinux127@lemmy.zip 11 points 4 days ago

    I haven't had a issue with Windows in at least 8 years. Admittedly I primarily use Linux but still. It isn't the unstable mess people here thing it is. It isn't private in the least but that's a different story.

    [–] bitjunkie@lemmy.world 1 points 4 days ago (2 children)

    Too much typing. alias kill="kill -9"

    [–] SaltyIceteaMaker@lemmy.ml 2 points 4 days ago

    still too much typing. pull the plug of your pc

    [–] possiblylinux127@lemmy.zip 1 points 4 days ago (1 children)
    [–] bitjunkie@lemmy.world 1 points 2 days ago (1 children)

    Yes you have arrived at exactly my fucking point

    [–] possiblylinux127@lemmy.zip 1 points 2 days ago
    [–] flying_sheep@lemmy.ml 47 points 4 days ago (2 children)

    Tbf, thanks to X11 Linux isn't safe from stuff like that.

    When I use my VR glasses, Steam sometimes creates an uncloseable X window that isn't attached to any process. I don't think even killing XWayland gets rid of it.

    [–] fallingcats@discuss.tchncs.de 43 points 4 days ago (3 children)

    On Plasma Desktop, pressing Ctrl+Alt+ESC kills anything you click on next, instantly. There is truly nothing you can't kill that way, even the desktop itself.

    [–] Jumuta@sh.itjust.works 12 points 4 days ago

    wow that sounds so handy, thanks

    [–] flying_sheep@lemmy.ml 7 points 4 days ago (1 children)

    Don't think I haven't tried that.

    I also tried the debug menu, xkill using the window ID, … it's immortal.

    [–] SturgiesYrFase@lemmy.ml 8 points 4 days ago (1 children)

    Have you tried silver, crosses or a stake?

    [–] filcuk@lemmy.zip 2 points 3 days ago (1 children)

    Do I need to #include those first?

    [–] SturgiesYrFase@lemmy.ml 1 points 3 days ago

    Haven't had to use them recently, check out the man?

    [–] far_university190@feddit.org 4 points 4 days ago (2 children)

    is that just shortcut to xkill? or own system?

    [–] fallingcats@discuss.tchncs.de 3 points 4 days ago

    I don't know, but I think it's works on Wayland too. Probably something built in.

    [–] Darorad@lemmy.world 2 points 3 days ago

    I assume it's a different system since it works on Wayland, but idk

    [–] Sabata11792@ani.social 5 points 4 days ago

    I've run into this, seems like steam VR can't relaunch properly unless you close till that dead window with a reboot.

    [–] mvirts@lemmy.world 5 points 3 days ago (1 children)

    Imho desktop Linux is usually set up where a single bad app can lock up the whole system. This is not every Linux system, but I run across it more than I would like. I believe part of this is an optimistic approach to memory management which makes the system run better overall most of the time.

    Windows seems slow as hell most of the time, but killing a process seems to work reliably (not clicking on the hung app takeover UI, using task kill or task manager)

    I don't understand these memes about killing processes in Linux vs Windows.

    [–] RoidingOldMan@lemmy.world 3 points 3 days ago

    The killing process on Windows used to work better. Since about Windows 8 it's not been quite the same.

    sudo xkill on mint, any cool sounding replacement for Wayland? as it seems like xkill is x11 olny.

    [–] BearOfaTime@lemm.ee 7 points 3 days ago (1 children)

    Quite often double click on the close button will kill a hung app on Windows. Not Al the time, maybe 70%.

    [–] pool_spray_098@lemmy.world 2 points 3 days ago

    For real? Can't believe I've never heard of this.

    [–] rain_worl@lemmy.world 8 points 4 days ago

    think both of them wait a while, and then ask if you want to eviscerate it

    [–] TunaCowboy@lemmy.world 9 points 4 days ago

    $ kill -l

     1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
     6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
    11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
    16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
    21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
    26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
    31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
    38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
    43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
    48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
    53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
    58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
    63) SIGRTMAX-1	64) SIGRTMAX
    
    [–] tomjuggler@lemmy.world 1 points 3 days ago

    Good one! I'm literally dealing with this right now on a server. Turns out you're expected to deal with long running processes that spawn too many threads yourself, or else....