This question already has answers here:
How do I shut down a python simpleHTTPserver?
(9 answers)
Closed 7 years ago.
I've started a SimpleHTTPServer via the command python -m SimpleHTTPServer 9001.
I'd like to stop it without having to force quit Terminal. What's the keystrokes required to stop it?
CTRL + C is usually the right way to kill the process and leave your terminal open.
Use CTRL+C.
This is a filler text because answer must be 30 characters.
Agree with Ctrl-C answer. Note that pressing Ctrl-C sends 'interrupt' signal (signal number 2).
Alternatively you can use TERM signal to terminate your server process.
You can send 'INT' or 'TERM' signal to request termination. Typically all good programs honor int and term signal and do cleanup.
To terminate a process properly, run
kill -2 <pid>
kill -15 <pid>
or
kill -INT <pid>
kill -TERM <pid>
There is a difference in SIGINT and SIGTERM. From this quora article,
SIGINT is the interrupt signal. The terminal sends it to the foreground process when the user presses ctrl-c. The default behavior is to terminate the process, but it can be caught or ignored. The intention is to provide a mechanism for an orderly, graceful shutdown.
SIGTERM is the termination signal. The default behavior is to terminate the process, but it also can be caught or ignored. The intention is to kill the process, gracefully or not, but to first allow it a chance to cleanup.
So use the right signal depending on your needs.
Related
Quick Question: What signal/Exception does PyCharm's Stop Button send when debugging a python script?
Background: Several posts document that hitting Ctrl-C doesn't send a Keyboard Interrupt/SIGINT signal to a python script when using PyCharm's Debugger. Fine. My question is, what does get sent to the Python script when clicking the Debugger's "Stop Button". I'd like to re-write my code to catch whatever that signal/Exception is. [I'm using OSX w/PyCharm 4.0.4]
When you stop the process after debugging it, it sends a SIGKILL signal to the interpreter.
Process finished with exit code 137
Exit codes above 128 mean that it's a 128 + a signal's number (in this case, 9, which is a SIGKILL).
You could catch SIGTERM using signal.signal(), but SIGKILL can't be caught. There's nothing you can do with it.
Well, you could set up a separate script that would monitor the first one (checking for its PID existance in the running processes, for example) and do something if the given process is terminated.
The problem being that SIGKILL cannot be caught, is there a way to ensure that a block of code gets executed on program termination? I have a process that starts five subprocesses and changes the state of platform hardware - it handles SIGTERM and SIGINT, however a SIGKILL will kill the main process while the subprocesses continue to run. Is there a way to always execute a cleanup or do I have to accept that SIGKILL will leave the computer in a 'corrupt' state?
SIGKILL cannot be handled. This signal used for critical cases where you dont want the program to be able to ignore the signal and you want to force it to be killed.
SIGTERM is the complement, this need to be use when you want to let the program cleanup before it closed
for more information you can read: http://en.wikipedia.org/wiki/Unix_signal#Handling_signals
well, I have a usr1 signal handler in a script. By sending a SIGUSR1 from outside to my script, my handler does its work, but the signal is spread also to the child that I create via Popen. How can I do this?
The rsync manual page says that exit code 20 means:
Received SIGUSR1 or SIGINT
So if you are killing it with kill (not kill -15 which you say you sometimes use) then it would die with this exit code too.
I have a simple example:
from twisted.internet import utils,reactor
def test:
utils.getProcessOutput(executable="/bin/sleep",args=["10000"])
reactor.callWhenRunning(test)
reactor.run()
when I send signal "TERM" to program, "sleep" continues to be carried out, when I press Ctrl-C on keyboard "sleep" stopping. ( Ctrl-C is not equivalent signal TERM ?) Why ? How to kill "sleep" after send signal "TERM" to this program ?
Ctrl-C sends SIGINT to the entire foreground process group. That means it gets send to your Twisted program and to the sleep child process.
If you want to kill the sleep process whenever the Python process is going to exit, then you may want a before shutdown trigger:
def killSleep():
# Do it, somehow
reactor.addSystemEventTrigger('before', 'shutdown', killSleep)
As your example code is written, killSleep is difficult to implement. getProcessOutput doesn't give you something that easily allows the child to be killed (for example, you don't know its pid). If you use reactor.spawnProcess and a custom ProcessProtocol, this problem is solved though - the ProcessProtocol will be connected to a process transport which has a signalProcess method which you can use to send a SIGTERM (or whatever you like) to the child process.
You could also ignore SIGINT and this point and then manually deliver it to the whole process group:
import os, signal
def killGroup():
signal.signal(signal.SIGINT, signal.SIG_IGN)
os.kill(-os.getpgid(os.getpid()), signal.SIGINT)
reactor.addSystemEventTrigger('before', 'shutdown', killGroup)
Ignore SIGINT because the Twisted process is already shutting down and another signal won't do any good (and will probably confuse it or at least lead to spurious errors being reported). Sending a signal to -os.getpgid(os.getpid()) is how to send it to your entire process group.
When using mpirun, is it possible to catch signals (for example, the SIGINT generated by ^C) in the code being run?
For example, I'm running a parallelized python code. I can except KeyboardInterrupt to catch those errors when running python blah.py by itself, but I can't when doing mpirun -np 1 python blah.py.
Does anyone have a suggestion? Even finding how to catch signals in a C or C++ compiled program would be a helpful start.
If I send a signal to the spawned Python processes, they can handle the signals properly; however, signals sent to the parent orterun process (i.e. from exceeding wall time on a cluster, or pressing control-C in a terminal) will kill everything immediately.
I think it is really implementation dependent.
In SLURM, I tried to use sbatch --signal USR1#30 to send SIGUSR1 (whose signum is 30,10 or 16) to the program launched by srun commands. And the process received signal SIGUSR1 = 10.
For platform MPI of IBM, according to https://www.ibm.com/support/knowledgecenter/en/SSF4ZA_9.1.4/pmpi_guide/signal_propagation.html
SIGINT, SIGUSR1, SIGUSR2 will be bypassed to processes.
In MPICH, SIGUSR1 is used by the process manager for internal notification of abnormal failures.
ref: http://lists.mpich.org/pipermail/discuss/2014-October/003242.html>
Open MPI on the other had will forward SIGUSR1 and SIGUSR2 from mpiexec to the other processes.
ref: http://www.open-mpi.org/doc/v1.6/man1/mpirun.1.php#sect14>
For IntelMPI, according to https://software.intel.com/en-us/mpi-developer-reference-linux-hydra-environment-variables
I_MPI_JOB_SIGNAL_PROPAGATION and I_MPI_JOB_TIMEOUT_SIGNAL can be set to send signal.
Another thing worth notice: For many python scripts, they will invoke other library or codes through cython, and if the SIGUSR1 is caught by the sub-process, something unwanted might happen.
If you use mpirun --nw, then mpirun itself should terminate as soon as it's started the subprocesses, instead of waiting for their termination; if that's acceptable then I believe your processes would be able to catch their own signals.
The signal module supports setting signal handlers using signal.signal:
Set the handler for signal signalnum to the function handler. handler can be a callable Python object taking two arguments (see below), or one of the special values signal.SIG_IGN or signal.SIG_DFL. The previous signal handler will be returned ...
import signal
def ignore(sig, stack):
print "I'm ignoring signal %d" % (sig, )
signal.signal(signal.SIGINT, ignore)
while True: pass
If you send a SIGINT to a Python interpreter running this script (via kill -INT <pid>), it will print a message and simply continue to run.