Is there any way to kill a program that ignores all exceptions? Stupid, I know. I was testing something (since I wasn't sure what error a failed, embedded pig script would throw), forgot to limit the loop to a single day, and now it's just continuously running even though I used
ps -ef
to find and directly kill it. I would just let it run to completion since it will definitely terminate, but it runs hadoop jobs, and is needlessly using up resources/popping up on the terminal in between other tasks randomly. I'd like to avoid shutting my desktop down since I'm running other tasks, but will if it'll kill it...
I got the pid from
ps -ef
and used
kill -9
to directly kill it. It no longer shows up when I run
ps -ef | grep
but when I leave my terminal sitting for a little bit (even a new window) these "ghost" hadoop jobs show up that correspond to where the killed task would be.
Normally your Python program would need registered listeners to handle any kill signal you send it. See here:
https://stackoverflow.com/a/1112350/276949
There is a special kill signal (SIGKILL, denoted by-9) which will kill your process no matter what.
kill -9 <pid>
Related
Got a script for activating a python venv and running a server in the background, but right now I am trying to keep the pid when I start the process and then kill the process with pid after I am done. However, it is not all the time is gets killed.
My question is, can I run the process with a name, then killing it by using pkill name after? and how will that look
#!/bin/sh
ROOT_DIR=$(pwd)
activate(){
source $ROOT_DIR/.venv/bin/activate
python3 src/server.py -l & pid=$! # <== This is the process
python3 src/client.py localhost 8080
}
activate
sleep 10
kill "$pid"
printf "\n\nServer is done, terminating processes..."
You can run programs with a specific command name by using the bash buildin exec. Note that exec replaces the shell with the command so you have to run it in a subshell environment like:
( exec -a my_new_name my_old_command ) &
However, it probably won't help you much because this sets the command line name, which is apparently different from the command name. So executing the above snippet will show your process as "my_new_name" for example in top or htop, but pkill and killall are filtering by the command name and will thus not find a process called "my_new_name".
While it is interesting, how one can start a command with a different name than the executable, it is most likely not the cause of your problem. PIDs never change, so I assume that the problem lays somewhere different.
My best guess is that the server binds a socket to listen on a specific port. If the program is not shutdown gracefully but killed the port number remains occupied and is only freed by the kernel after some time during some kind of kernel garbage collect. If the program is restarted after a short period of time it finds the port already been occupied and prints a misleading message, that says it is already running. If that is indeed the cause of your problem I would strongly consider implementing a way to graceful shutdown the server. (may be already closing the socket in a destructor or something similar could help)
I think you should have to use systemd for this case:
https://github.com/torfsen/python-systemd-tutorial
I want to achieve this.
I can run the process by os.system('PROCESS_NAME &')
But I don't know how to kill it.
And I don't wanna the external process blocking in my process
run external daemon process
do my jobs, do anything
kill the `running external daemon process`
On Linux OS, I wonder kill the task when meets some requirement
In a project I am working on, there is some code that starts up a long-running process using sudo:
subprocess.Popen(['sudo', '/usr/bin/somecommand', ...])
I would like to clean up this process when the parent exits. Currently, the subprocess keeps running when the parent exits (re-attached to init, of course).
I am not sure of the best solution to this problem. The code is limited to only running certain commands via sudo, and granting blanket authority to run sudo kill would be sketchy at best.
I don't have an open pipe to the child process that I can close (the child process is not reading from stdin), and I am not able to modify the code of the child process.
Are there any other mechanisms that might work in this situation?
First of all I just answer the question. Though I do not think it is a good thing to do, it is what you asked for. I would wrap that child process into a small program that can listen stdin. Then you may sudo that program, and it will be able to run the process without sudo, and will know its pid and have the rights needed to kill the process when you ask it through stdin to do so.
However, generally such a situation means sudo with no password and poor security. The most common technique is to use lowering your program's privileges, not elevating them. In such case you should create a runner program that is started by superuser, than it starts your main program with lowering of privileges and listens for a pipe to communicate. When it is necessary to run a command, your main program tells that to the runner program, and runner program does the job. When it is necessary to terminate command, you again tell this to a runner program via the pipe.
The common rules are:
If you need superuser rights, you should give them to the very parent process.
If a child process needs to do a privileged operation, it requests the top-level process to do that for him.
The top-level process should be kept as small as possible and do as little as possible. The larger it is, the more holes in security it creates.
That's what many applications do. The first example that comes into my mind is Apache web server (at least on *nix) that has a small top-level program and preforked working programs that are not run as root/wheel/whatever-else-is-the-superuser-username.
This will raise OSError: [Errno 1] Operation not permitted on the last line:
p = subprocess.Popen(['sudo', '/usr/bin/somecommand', ...])
print p.stdout.read()
p.terminate()
Assuming sudo will not ask for a password, one workaround is to make a shell script which calls sudo …
#!/bin/sh
sudo /usr/bin/somecommand
… and then do this in Python:
p = subprocess.Popen("/path/to/script.sh", cwd="/path/to")
print p.stdout.read()
p.terminate()
Using parallel python 1.6.4 I spawn a subprocess.Popen command on a remote server. For whatever reason, the command isn't completing in a timely matter, i.e., within the socket_timeout I've set. In this case, I expected parallel python to fail, kill the remote process, and maybe raise an exception. Instead, the long process keeps running, and the ppserver quietly spawns another one!
How can I configure ppserver to fail?
Short of that, I suppose I have to set timer, and destroy the job_server to make it close out and clean up the bad process?
I ran a simple web server using
python -m simpleHTTPServer 8888 &.
it starts well. Then used ctrl+C to attempt to terminate it, and I go to
http://localhost:8888/
and the server is still running. Am I doing something wrong?
I am using zsh for terminal, not sure if this has anything to do with it.
It’s because of the & that causes the command to be run in background. After you started the process, you get the process id. Using that id, you can kill the process:
$ python &
[1] 5050
$ kill -15 5050
[1]+ Angehalten python
If sending a SIGTERM signal (-15) does not work, you can use SIGKILL (-9).
Edited to use SIGTERM instead of SIGKILL, see #starrify’s comment.
CTRL+C sends SIGINT. You should send a kill signal using kill -9 pid to kill the process
I don't know whether you need &. here. However in most of the shells (of course zsh is included) the symbol & mean to start this task in the background, which means your CTRL+C is actually not received by the application.
Try remove the &. and see what would happen.
EDITED: See #RobinKrahl's answer for how to terminate the process by sending a signal to it using kill. However for terminating a finely working process I suggest use SIGTERM (signal number 15) instead of SIGKILL (signal number 9).
It's because of &. It is now a background process which you cannot kill by ctrl+c.
As it is server, I recommend you to use &. To kill off the server, do -> ps aux | grep simpleHTTPServer to find the process id and then do kill -9 pid
TLDR: If sending a SIGKILL doesn't work, as a last resort try killall python
I ran into a similar problem in which the localhost server would simply change to another pid even after I gave it a SIGKILL. The only thing that worked for me, and would probably work as a last resort for anyone else experiencing this would be to simply run in bash: killall python.