- cross-posted to:
- linuxsucks@lemmy.world
- cross-posted to:
- linuxsucks@lemmy.world
Seen on the FOSS Weekly #24.44: https://itsfoss.com/newsletter/foss-weekly-24-44/
kill -9
😎kill -15
Terminate normally if possible.
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.
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.)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.
think both of them wait a while, and then ask if you want to eviscerate it
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
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.
The killing process on Windows used to work better. Since about Windows 8 it’s not been quite the same.
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…