Is there easy way to kill a process using its process ID (pid_t in Linux and PROCESS_INFORMATION::dwProcessId in Windows)?
linux: kill(pid, SIGKILL);
Windows: TerminateProcess(Handle, 1) where you get Handle from OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwProcessId);
Note that both of these will simply kill the process, the target is given no chance to shut down properly. If you want to let the target get a chance to do this, use SIGHUP and then SIGTERM on linux. For windows, you could send WM_SYSCOMMAND/SC_CLOSE if you have the target applications main window handle, this can be found with EnumWindows and GetWindowThreadProcessId
Related
Our teachers told us to experiment with the terminal and kill -9 -1
To my understanding, on UNIX based OS, the first process charged is Init with PID -1 from which the other processes will spawn. I assumed that you couldn't kill it as it is charged in a secured part of memory.
On a VM running LinuxMint, the command would would cause the session to close itself. On MacOS, it would close/crahs(?) all applications.
On some other people laptops running different distribution of Linux the command would be denied which was the behaviour I would have expected in any OS.
So I am confused by the behaviour of the command.
What should be the normal result? Or is it bound to each OS implementation?
Thanks.
The general behaviour, from Kill MAN page:
If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init)
So, "kill -9 -1" will kill all processes it can.
I have an CLI app that is seg faulting during termination (After sending a Ctrl-C)
Pressing Ctrl-C in lldb naturally pauses execution.
Then I try:
(lldb)process signal SIGINT
(lldb)process continue
But that doesn't actually seem to do anything to terminate the app.
Also tried:
(lldb)process signal 2
The debugger uses ^C for interrupting the target, so it assumes that you don't actually want the ^C propagated to the target. You can change this behavior by using the "process handle" command:
(lldb) process handle SIGINT -p true
telling lldb to "pass" SIGINT to the process.
If you had stopped the process in lldb by issuing a ^C, then when you change the process handle as shown here and continue, that SIGINT will be forwarded to the process.
If you stopped for some other reason, after specifying SIGINT to be passed to the process, you can generate a SIGINT by getting the PID of the debugee using the process status and send a SIGINT directly to said process using platform shell:
(lldb) process status
(lldb) platform shell kill -INT {{PID from previous step}}
(lldb) continue
The easiest way I found was just to send the process a SIGINT directly. Take the pid of the debuggee process (which process status will show you) and run
kill -INT <pid>
from another terminal.
I'm writing a script to start Jboss, load an application, send requests to the application, shutdown jboss and repeat. However I dont know how to shut Jboss down from the script. At the moment I'm using
pkill -9 java
But I dont think this is right, because it kills the process, not shut it down. Is there a way to shut it down similar to pressing CTRL-C?
You want a simple
pkill java
From the man page:
pkill will send the specified signal (by default SIGTERM) to each
process
SIGTERM will send a termination signal to the process. If the process is well-written, it will catch this signal and perform an orderly shutdown. If that fails, that's when you can use SIGKILL (-9) which is a forceable termination with no chance for the process to catch and perform cleanup.
Never use kill -9 <PID> by default. It breaks things up, like file descriptors and such.
Start to run kill <PID> alone, default is -15 signal.
See
man 7 signal
And In what order should I send signals to gracefully shutdown processes?
NOTE
kill or pkill doesn't change things so much, same signals are trigered
What you actually want is:
pkill -f jboss
using pkill java could kill any other processes using java on the box.
My console app traps SIGINT so it can exit gracefully.
Pressing CTRL+C inside XCode while the program is being debugged, though, has no effect.
I can find the process and use a terminal window to send a SIGINT to my process, however I'm hoping there's a simpler solution that I can do within XCode.
The pause button of the debugger console actually sends a SIGINT to your app.
If you want to make the debugger pass the signal to your app you can do the following:
Press the pause button of the debugger and wait for the debug console to gain focus
Type handle SIGINT pass and press ENTER
Press the Continue button
Now pressing again the Pause button of the debugger console of Xcode will make the SIGINT hit your app.
If you don't want the debugger to stop as soon as the SIGINT is caught you might also want to add handle SIGINT nostop to the previous list.
Update for 2017 / Xcode 8: the proper command(s) for informing lldb of your intention for handling interrupts:
process handle SIGINT -s false
process handle SIGINT -p true
In my experience, even with the above commands, the pause feature of the debugger still will interrupt the app and yield control to the debugger's stack pointer, however a pkill -2 appname at the terminal will trigger your interrupt function without any interaction with the debugger, for example:
void on_signal(int sig) {
is_interrupted = 1;
}
int main(int argc, const char * argv[]) {
signal(SIGINT, on_signal);
// ... do stuff
}
In Xcode 5+ (llvm):
Pause the process
At the (llvm) prompt, enter process signal SIGINT
Resume execution
One solution is to use the UNIX kill or killall commands.
If you know the Process ID you can open the Terminal application and type:
kill -SIGINT 415
(where 415 is the PID for this process)
Or, perhaps easier, you can type
killall -SIGINT my_console_app
(where my_console_app is the name of your app, i.e. the name of the binary created — not the bundle if it's in one)
This will send the signal to all instances of the application, as the name killall suggests, so it may not be appropriate. It might be worth checking if there are other processes with the same name running before you do a killall (;
One of the work-arounds to the hassel of working with interrupts is making a MainMenu with a CTRL-C short-cut that executes your requested routine, or sends itself a SIGINT, if you really need the sig.
Update for XCode 12+
In the modern versions of XCode it is hard to intercept SIGINT. For debug purposes it is better to use SIGINFO in place of SIGINT. You can generate that in Terminal using ^T (CTRL+T).
So during debugging temporary replace SIGINT with SIGINFO in your code. To intercept SIGINFO try next steps all together:
Go to Product > Scheme > Edit Scheme > Run > Options and change Console from Use Xcode to Use Terminal.
Run your program
Pause the program
In the Xcode console, enter this:
(lldb) process handle -p true -s false -n false SIGINFO
You will get:
NAME PASS STOP NOTIFY
=========== ===== ===== ======
SIGINFO true false false
Resume the program
Switch to Terminal and press CTRL+T.
Your signal handler will fire.
Don't forget to return SIGINT back after finishing debugging!
I'm running a script that performs a command that lasts too long, so I want to interrupt it. Any help? I've tried to search a lot, and I've been pointed to the kill command. Although, I can't get it to work. By the way, I'm using a Mac OS X. Thanks!
Assuming you have the process' PID, send it a SIGINT signal:
kill -SIGINT PID
If you don't have the PID you can try pkill or killall, but they're somewhat less safe; a PID is the only way to uniquely identify a process. Right after you spawn the other process the PID should be in $!, so you can save it then
process-that-takes-a-long-time &
pid=$!
# other stuff
kill -SIGINT $pid
timeout 10 your_command
To replicate Linux Ctrl+C on a terminal on Mac OS X, use ctrl+C!
Its the same keystroke combination
Worked for me (first Steps on Mac)
edit: I didnt read the script is running in background.