Hot answers tagged

244

There are many ways to go about this. Method #1 - ps You can use the ps command to find the process ID for this process and then use the PID to kill the process. Example $ ps -eaf | grep [w]get saml 1713 1709 0 Dec10 pts/0 00:00:00 wget ... $ kill 1713 Method #2 - pgrep You can also find the process ID using pgrep. Example $ pgrep wget ...


88

What's wrong with the good old, for pid in $(ps -ef | grep "some search" | awk '{print $2}'); do kill -9 $pid; done There are ways to make that more efficient, for pid in $(ps -ef | awk '/some search/ {print $2}'); do kill -9 $pid; done and other variations, but at the basic level, it's always worked for me.


84

You can use : pkill screen Or killall screen In OSX the process is called SCREEN in all caps. So, use: pkill SCREEN Or killall SCREEN


80

If you did not put the software there and/or if you think your cloud instance is compromised: Take it off-line, delete it, and rebuild it from scratch (but read the link below first). It does not belong to you anymore, you can not trust it any longer. See "How to deal with a compromised server" on ServerFault for further information about what to do and how ...


76

It should always be OK to do kill -9, just like it should always be OK to shutdown by pulling the power cable. It may be anti-social, and leave some recovery to do, but it ought to work, and is a power tool for the impatient. I say this as someone who will try plain kill (15) first, because it does give a program a chance to do some cleanup -- perhaps ...


76

If the file(s) in question contain really lots of data sending the signal can actually get to cat before it finishes. What you really observe is the finite speed of your terminal - cat sends the data to the terminal and it takes some time for the terminal to display all of it. Remember, that usually it has to somehow redraw the whole output window for each ...


74

This one is a little hard to glean but if you look in the following 2 man pages you'll see the following notes: kill(1) $ man 1 kill ... If sig is 0, then no signal is sent, but error checking is still performed. ... kill(2) $ man 2 kill ... If sig is 0, then no signal is sent, but error checking is still performed; this can be used to check for the ...


71

Sending kill -9 to a process doesn't require the process' cooperation (like handling a signal), it just kills it off. You're presuming that because some signals can be caught and ignored they all involve cooperation. But as per man 2 signal, "the signals SIGKILL and SIGSTOP cannot be caught or ignored". SIGTERM can be caught, which is why plain kill is ...


69

It can. There are 2 different out of memory conditions you can encounter in linux. Which you encounter depends on the value of sysctl vm.overcommit_memory (/proc/sys/vm/overcommit_memory) Introduction: The kernel can perform what is called 'memory overcommit'. This is when the kernel allocates programs more memory than is really present in the system. This ...


66

pgrep/pkill take a -f flag. From the man page: -f The pattern is normally only matched against the process name. When -f is set, the full command line is used. For example: $ sleep 30& sleep 60& [1] 8007 [2] 8008 $ pkill -f 'sleep 30' [1] - terminated sleep 30 $ pgrep sleep 8008


66

In bash you can use fg to get the job to the foreground and then use Ctrl+C Or list the process in the background with jobs and then do kill %1 (with 1 replaced by the number jobs gave you)


65

The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel. When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time for running user-space code. If the process has any threads executing user-space code on other CPUs/cores at the ...


59

Processes can call the _exit() system call (on Linux, see also exit_group()) with an integer argument to report an exit code to their parent. Though it's an integer, only the 8 least significant bits are available to the parent (exception to that is when using waitid() or handler on SIGCHLD in the parent to retrieve that code, though not on Linux). The ...


54

Indeed, the original purpose of a signal was to kill the target process. kill appeared in Unix 3rd Edition; at the time, it was reserved to root and the process was forcibly killed (like SIGKILL today) and left a core dump. Unix 4th edition added a signal number argument, as well as the companion signal system call to set a signal handler. At the time, all ...


51

You can always try the obvious things like ^C, ^D (eof), Escape etc., but if all fails I usually end up suspending the command with ^Z (Control-Z) which puts me back into the shell. I then do a ps command and note the PID (process id) of the command and then issue a kill thePID (kill -9 thePID if the former didn't work) command to terminate the application....


51

kill [ -s signal | -p ] This syntax in a manual page means: You can use kill -s signal or you can use kill -p, but you can't use both -s and -p at the same time. The pipe (|) stands for (exclusive) or in the documentation, it's not part of the command. When you type foo | bar in your shell, it will attempt to start foo and bar, and pipe the output of ...


47

SIGKILL never fails to kill a running process, that's the point. Other signals exist to give the application a chance to react. The default behavior of SIGINT, SIGTERM, SIGQUIT and SIGHUP is to kill the program. However applications are allowed to install a handler for these signals. So the actual behavior of applications when they receive these signals is ...


42

Read its documentation. That's the only way. As Keith already wrote, the original meaning of SIGHUP was that the user had lost access to the program, and so interactive programs should die. Daemons — programs that don't interact directly with the user — have no need for this behavior and instead often reload their configuration files when they receive SIGHUP....


42

The pgrep and pkill utilities were introduced in Sun's Solaris 7 and, as g33klord noted, they take a pattern as argument which is matched against the names of running processes. While pgrep merely prints a list of matching processes, pkill will send the specified signal (or SIGTERM by default) to the processes. The common options and semantics between pgrep ...


42

Update This is one of those ones where I clearly should have read the question more carefully (though seemingly this is the case with most answers on to this question). I have left the original answer intact because it gives some good information, even though it clearly misses the point of the question. Using SID I think the most general, robust approach ...


39

Make the password manager run under a separate user. You can't send signals to (=kill) processes run under a different user unless you're root. All processes will still be killable by root. For closer details, see kill(2).


39

You can't kill a Zombie (process), it is already dead. It is just waiting for its parent process to do wait(2) and collect its exit status. It won't take any resource on the system other than a process table entry. You can send SIGCHLD to its parent to let it know that one of its children has terminated (i.e. request it to collect child's exit status). This ...


38

I use kill -9 in much the same way that I throw kitchen implements in the dishwasher: if a kitchen implement is ruined by the dishwasher then I don't want it. The same goes for most programs (even databases): if I can't kill them without things going haywire, I don't really want to use them. (And if you happen to use one of these non-databases that ...


37

Use killall, killall vi This will kill all command named 'vi' You might also add a signal as well, e.g SIGKILL killall -9 vi


37

SIGSTOP and SIGKILL are two signals that cannot be caught and handled by a process. SIGTSTP is like SIGSTOP except that it can be caught and handled. The SIGSTOP and SIGTSTP signals stop a process in its tracks, ready for SIGCONT. When you send that process a SIGTERM, the process isn't running and so it cannot run the code to exit. (There are also SIGTTIN ...


35

You cannot kill a <defunct> (also known as zombie) process as it is already dead. The only reason why the system keeps zombie processes is to keep the exit status for the parent to collect. If the parent does not collect the exit status then the zombie processes will stay around forever. The only way to get rid of those zombie processes are by killing ...


35

After the first Ctrl-C, the program will receive SIGINT and usually starts cleaning up (deleting tmp files, closing sockets, etc.). If you hit Ctrl-C again while that is going on, it may happen that you interrupt the clean up routine (i.e. the additional signal might be acted upon instead of being left alone), leaving a mess behind. While this usually is not ...


34

What it does is entirely application specific. When you press ctrl+c, the terminal emulator sends a SIGINT signal to the foreground application, which triggers the appropriate "signal handler". The default signal handler for SIGINT terminates the application. But any program can install its own signal handler for SIGINT (including a signal handler that ...


34

When tee terminates, the command feeding it will continue to run, until it attempts to write more output. Then it will get a SIGPIPE (13 on most systems) for trying to write to a pipe with no readers. If you modify your script to trap SIGPIPE and take some appropriate action (like, stop writing output), then you should be able to have it continue after tee ...


33

From man 2 kill: The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. That is, it is possible for init to do whatever it likes upon receiving SIGKILL (including exiting), but systemd's init does not ...


Only top voted, non community-wiki answers of a minimum length are eligible