Yes yes, I REALLY want to terminate that process and I am very sure about it too, ty.
TerminateProcess() is pretty reliable, but it doesn’t form part of the C signals stack on Windows like kill -9. So for instance, if you’re doing process control on Python, you need to use a special Windows-only API to access TerminateProcess().
Never used kill -9. What’s the difference between that and taskkill. I usually used taskkill /pid processiwanttokill.exe /f
Kill -9 is a command on Unix and Linux to send signal 9 (SIGKILL) to a process. That’s the version of kill that is the most reliable and has immediate effect.
Taskkill is a Windows command line program. I believe that taskkill /f uses the TerminateProcess() API. This is more forceful than the End Task button on the Task Manager. There is a different End Process button on the Task Manager that does use TerminateProcess().
Is the 9 pertaining to permissions like chmod uses them? I’ll have to look it up sometime. Been awhile since I’ve ever actually needed to force quit something in a Linux os
No, it’s just the number of a specific signal.
Thanks for that, I’ll have a ganter. Need to spin up a new VM soon and figure out a new distro to play with. Been slacking on exploring new things. Mostly only played with Yellow dog (small enough to dual boot on a PS3 with 512mb of ram back in the day), Ubuntu, Debian for other things. Likely will look for something that will work well for a media server.
Have fun exploring! I just have a simple Raspberry Pi at home with a few services, after working with this stuff all the time I rarely feel like tinkering at home :D
Sigterm: “End this process or next time I bring my -9”
My tec-9
I feel like I’ve had the opposite experience in the gui (maybe a KDE issue?) closing gui windows frequently lock up, and I find I frequently have to drop to the command line in order to properly kill some programs
That’s because the end proces of the GUI sends a sigint, which does jack shit if the program hangs, you only archieve for a higher parent process to obtain it until it can off itself gracefully. You need to right click the process and send a sigkill signal to emulate the command line.
mainly wrong, by default kill send a SIGTERM, you can try SIGINT or SIGQUIT too, and in the end SIGKILL of course. Same in windows there is different way
I always go straight for the SIGKILL
Some software: fork()
Me: Welcome to the process gauntlet loser, better not hang for a millisecond or you are dead and gone.Every time you SIGKILL, a poorly-drawn penguin dies!
And as always with this meme: Both Windows and Linux can ask a process nicely to terminate or kill it outright. And the default for both is to ask nicely.
Windows can kill a process outright.
Hmmmm…
Taskkill /f is reasonably close to sudo kill -9
Hitting the X in Windows and hitting the X in Linux both cause the application to start a save yourself routine. From the OS standpoint they’re not far off.
The problem is we have a lot of confirmation bias in windows because every time we want to close an application that’s not working, that save yourself call has to sit around for a hellaciously long time out followed by a telemetry call so that Microsoft can track that it happened.
It’s pretty rare that Linux apps don’t just close.
Next, you’ll tell me I shouldn’t get all my news from memes!
on windows a process can get in a state so that it is impossible to make it go away, even with process explorer or process hacker. mostly this also involves the bugged software becoming unusable.
I encounter such a situation from time to time. one way it could happen is if the USB controller has got in an invalid state, which one of my pendrives can semi-reliably reproduce. when that happens, any process attempting to deal with that device or its FS, even the built-in program to remove the drive letter, will stop working and hang as an unkillable process.
Linux has that issue too. A process in an uninterruptible blocking syscall stays until that syscall finishes, which can be never if something weird’s going on.
oh, that’s good to know! iirc that’s the same reason it happens on windows too
I’ve seen that on Linux as well. Funnily enough also with faulty file systems. I think NFS with spotty wifi for one.
Oh, and once with a dying RAID controller. That was a pain in the ass. At that point I swore to only ever do RAID in software.
oh yeah now that you say, SMB/CIFS mounted share if connection is no more. when I experienced this, it was temporary though, because there’s a timeout which is half (or double?) of the configurable reconnection timeout. but now that I think of it, I’m not sure if it made it unkillable.
Well, with linux you get the option of sending mixed signals through the use of varying count of guns. I find 9 to be highly effective.
Because that’s better for the software, Linux however kills it outright when it doesn’t respond at all. Windows just… Waits. And you can’t really hardkill the processes from the task manager. Or at last my last knowledge is that.
League of Legends captures and discards the ALT-F4 keystroke combination.
Microsoft trusts app developers to use Microsoft’s standards (such as terminating the process when a close message is received) and they shouldn’t. App developers like Riot have taken advantage of this trust and tuned their apps to act differently than expected, and include code which makes the app minimize to the system tray instead, or force the user to answer questions (“Are you SURE you want to close?”), or do nothing at all.
It should be punishable by death.
Linux programs can also capture signal calls. They usually only capture sigints so that they can close gracefully, but theoretically you could also capture a sigkill.
Thanks!
I mean, “are you sure” is useful… sometimes
You can easily make a program unkillable (or to be more precise untermable) on Linux. Here’s a simple bash script that will do that.
#!/bin/bash function finish { while true do echo "Can't kill me." sleep 10 done } trap finish EXIT trap finish TERM trap finish INT while true do echo "Still alive." sleep 10 done
How the OOM Killer asks a process to terminate:
indiscriminate spraying
ps aux | grep <process>. kill <pid>
kill -9 $(pidof <process>)
killall
works great for this.At that point you can just hard restart as well. Most motherboards accept 10 to 15 seconds of power button as “my OS is fucked please help” and restart the machine for you.
killall just kills all instances of a program, not everything.
and also, long pressing the power button should just shut it down, no?
They also accept pulling the power cord out as “oh no” and shutdown for you!
Typing “kill -9” into a terminal is the equivalent to breaking out the acetylene torch when a nut won’t budge
Can’t be tight if it’s liquid
xkill
is one of my favorite commandsIs there a Wayland equivalent?
I dunno; I sadly can’t use Wayland yet bc I have Nvidia
I don’t know if you heard, but the Nvidia issues are solved (mostly).
The issue most people had was with Explicit Sync, which was patched in the proprietary Nvidia driver 555 which is upstream on most distros.
idk if this could be subjective, but what do you mean by upstream here? Does that mean it’s included in most distros?
Good to know; I’ll check it out!
Open the process list in your system monitor of choice, right click, signal, sigkill.
You can also open a monitor and use top or any variant to detect the process number and manually
kill -KILL number
I really want the convenience of binding xkill to a key, which I can use to double tap programs like the undead zombie they’ve become.
Dunno, create a script that uses a program to get the process number of the current active window or the window the mouse is hovering, and then kill that? Bind that script inor a key with whatever program and voilá.
It’s more involved sure but there’s your option.
Great idea, now I just need to know how to do that.
What’s your desktop environment? I’m pretty sure hyperland and sway will give a json output of open Windows.
You could parse that with jq and pipe it into fzf or dmenu?
Not quite the same as the clicking but probably just as quick.
It even kills threads currently executing a system call! The brutality!
Never even returned to userspace…
both OS ask a process to end nicely? Then force closing in windows is with task manager or kill -9 in linux
My problem with Windows is that when I want to eject a USB drive, Windows refuses to do so, refuses to tell me what program is apparently still using the drive, and certainly refuses to kill that program. I am removing the drive. I can’t just not remove it!
Okay, yes. This fucking sucks and it happens all the time on Windows.
The worst part is that with Quick Removal it’s pretty much always safe to just remove it
At that point, you need to live dangerously and just yank it.
I’ve found that in those cases its usually explorer that’s the culprit. Just having the removable drive open in explorer is enough to keep windows from being able to unmount the drive.
btw funny story since many comments mention NFS/CIFS:
I have a share mounted at /smb and the server sometimes just dies so when I want to unmount it I run umount /smb but my shell (zsh) hangs after typing umount /sm and the b doesn’t even show
I guess zsh does a kind of stat() on everything you type but bash came to save the day
I don’t know if clean ZSH does it, but if you have the zsh-syntax-highlighting plugin, it tests if the path you’re typing exists every time you edit the line.
Enters the chat
I’ve honestly not had this problem on windows since Windows 8.