现象是这样的,有些时候python运行死了,就用任务管理器强制结束

过几秒又会自动启动出好多,可能一个,两个,三个python进程出来

杀了他们,过会又出来,如此反复,不能真正的杀死pytohn

有时候只是会多出几个来,杀了就不会再自启了,但是像永远杀不死的情况也是有发生过的

这样谁受得了啊,无限自启,还越来越多

有人遇到类似的问题吗?怎么解决?

就一段普通的代码(代码会造成线程死锁):

import threading

import time

class MyThread(threading.Thread):

def run(self):

global num

time.sleep(1)

if mutex.acquire(1):

num = num+1

msg = self.name+' run!'

print(msg)

# 卡在这里了,自身不release就要接着acquire,不可能

mutex.acquire()

print('acquire')

mutex.release()

print('release 1')

mutex.release()

print('release 2')

num = 0

mutex = threading.Lock()

def test():

for i in range(5):

t = MyThread()

t.start()

if __name__ == '__main__':

test()

换成正常运行的也是会出现类似的问题(这个可以正常运行):

import threading

import time

class MyThread(threading.Thread):

def run(self):

global num

time.sleep(1)

if mutex.acquire(1):

num = num+1

msg = self.name+' run!'

print(msg)

# 卡在这里了,自身不release就要接着acquire,不可能

# mutex.acquire()

# print('acquire')

# mutex.release()

# print('release 1')

mutex.release()

print('release 2')

num = 0

mutex = threading.Lock()

def test():

for i in range(5):

t = MyThread()

t.start()

if __name__ == '__main__':

test()

但是还是会出现上面的情况

kp是cmd命令:

taskkill /F /IM python.exe()

有时候又好了,比如现在:

就是不知道为什么会这样,明明程序中并没有用多进程还给我这么搞

代码不限于上面的那个,有些时候写些其他东西也会出现类似的情况

求解,谢谢!

是win7下,python3.6 64位,包装了好多(应该不是包的问题吧),python我觉得我的也没啥问题

我可能就是不知道pytohn运行机制吧

貌似找到了一个怀疑的原因:

我是用sublime text3写python,装过这些插件:

原来就发现某个插件(记不得名称了),会自动查找我代码的语法错误,它会运行我本地的pytohn,造成运行好几个python进程,造成我cpu占用过高(其实也没多高),然后我一怒之下就把那插件给卸载了

刚发生的状况为,我先kp掉所有的pytohn进程,然后切换回sublime text3中,发现sub test 假死,卡了1秒多,然后多了几个pytohn进程,十有八九吧,不是代码的问题233333

后来我关了sub,kp掉pytohn,打开sub,又多几个python,没跑了,十有八九,要不sub的问题,要不sub插件的问题

有了解sub插件的大佬嘛?求解释,大概应该是哪几个插件有问题?

还是我又理解错了,不是sub的问题??

谢谢

对了,刚关了sub,python就没了….

我是不是该抛弃sub了….

终于知道为啥要用vim写代码了,我感觉我代码有问题都是运行后编译器高速我的,sub感觉还算好用吧,要不就是我强迫症2333333

我试图避免像这样终止进程：

import subprocess

command = "pkill python"

process = subprocess.Popen(command.split(), stdout=subprocess.PIPE)

但是相反，我试图杀死一个特定的进程，而不是所有的python进程。假设process命令称为“ python test.py”，我想杀死该命令，而其他python进程保持完整。不知道我该怎么做。

平台是Linux / Ubuntu

澄清一下，这就是我执行ps -aux |时要完成的工作。grep“ python”我看到了：

sshum 12115 68.6 2.7 142036 13604 pts/0 R 11:11 0:13 python test.py &

sshum 12128 0.0 0.1 11744 904 pts/0 S+ 11:12 0:00 grep --color=auto test.py

我想杀死进程12115，但是我不确定如何在不杀死所有其他python进程的情况下进行此操作。

编辑：这是我想出的解决方案，但它看起来并不特别优雅...

command = "ps aux"

process = subprocess.Popen(command.split(), stdout=subprocess.PIPE)

output = process.communicate()[0].split("\n")

try:

for p in output:

if "python test.py" in p:

l = p.split(" ")

l = [x for x in l if x!='']

pid = int(l[1])

os.kill(pid, 9)

except:

pass

解决方案

pgrep(-f)中有一个标志，它允许在整个命令行中搜索进程，而不仅仅是名称。

ps aux|grep python尝试重现结果时在我的机器上的输出：

shadowk+ 1194 2.4 0.5 354240 70748 ? S 11:29 0:46 /usr/bin/python /usr/share/chronoslnx/main.py

shadowk+ 1239 0.1 0.6 508548 84080 ? Sl 11:29 0:03 /usr/bin/python2 /usr/share/kupfer/kupfer.py

shadowk+ 1245 0.0 0.4 296732 60956 ? S 11:29 0:00 /usr/bin/python2 -O /usr/share/wicd/gtk/wicd-client.py --tray

shadowk+ 2279 99.7 0.0 22800 7372 pts/3 R+ 12:00 0:30 /usr/bin/python ./test.py

shadowk+ 2289 0.0 0.0 10952 2332 pts/0 S+ 12:01 0:00 grep --color=auto python

就我而言，以下任何命令都将获取正在运行的./test py文件的PID：

pgrep -f 'python ./test.py'

pgrep -f 'test.py'

第二个代码更接近您要寻找的代码，因此调整后的代码如下所示(对于Python 2.x，您只需要从e.output中删除.decode()调用，并删除获取PID的调用)：

import subprocess

import os

try:

needed_pid=subprocess.check_output(['pgrep','-f','test.py']).decode()

except subprocess.CalledProcessError as e:

print("pgrep failed because ({}):".format(e.returncode) , e.output.decode())

else:

try:

os.kill(int(needed_pid), 9)

print("We killed test.py!")

except ProcessLookupError as e:

print("We tried to kill an old entry.")

except ValueError as e:

print("Well, there's no test.py...so...yeah.")

如果您想直接调用pkill进行相同的操作，也可以像这样更简单地执行此操作：

import subprocess

subprocess.call(['pkill', '-f', 'test.py'])

呃,我昨天刚刚研究一下这个！假设你不能改变子程序：

在Linux上,prctl(PR_SET_PDEATHSIG,…)可能是唯一可靠的选择. (如果绝对有必要杀死子进程,那么您可能需要将死亡信号设置为SIGKILL而不是SIGTERM;您链接的代码使用SIGTERM,但是如果孩子确实有选择忽略SIGTERM. )

在Windows上,最可靠的选择是使用Job object.这个想法是您创建一个“作业”(一种用于进程的容器),然后将子进程放入作业,并设置说明的魔术选项“当没有人持有该作业的”句柄“,然后杀死它中的进程”.默认情况下,作业的唯一“句柄”是您的父进程所持有的“handle”,当父进程中断时,操作系统将通过并关闭其所有句柄,然后注意,这意味着没有打开的句柄工作.因此,根据要求,它会杀死小孩. (如果您有多个子进程,则可以将它们全部分配给相同的作业.)This answer具有使用win32api模块执行此操作的示例代码.该代码使用CreateProcess来启动子代码,而不是subprocess.Popen.原因是它们需要为生成的子进程获取“进程句柄”,并且CreateProcess默认返回.如果你宁愿使用subprocess.Popen,那么这里是一个(未经测试的)该答案的代码副本,它使用subprocess.Popen和OpenProcess而不是CreateProcess：

import subprocess

import win32api

import win32con

import win32job

hJob = win32job.CreateJobObject(None, "")

extended_info = win32job.QueryInformationJobObject(hJob, win32job.JobObjectExtendedLimitInformation)

extended_info['BasicLimitInformation']['LimitFlags'] = win32job.JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE

win32job.SetInformationJobObject(hJob, win32job.JobObjectExtendedLimitInformation, extended_info)

child = subprocess.Popen(...)

# Convert process id to process handle:

perms = win32con.PROCESS_TERMINATE | win32con.PROCESS_SET_QUOTA

hProcess = win32api.OpenProcess(perms, False, child.pid)

win32job.AssignProcessToJobObject(hJob, hProcess)

在技​​术上,这里有一个很小的竞争条件,如果孩子在Popen和OpenProcess调用之间死亡,你可以决定是否要担心.

使用作业对象的一个​​缺点是,当在Vista或Win7上运行时,如果您的程序从Windows shell启动(即通过单击图标),那么可能会出现already be a job object assigned并尝试创建新的作业对象将失败. Win8修复这个(通过允许作业对象嵌套),或者如果你的程序是从命令行运行的话,那应该是正常的.

如果你可以修改孩子(例如,像使用多重处理一样),那么可能最好的选择是以某种方式将父代的PID传递给孩子(例如,作为命令行参数,或者在args =参数中进行multiprocessing.Process)接着：

在POSIX上：在孩子中产生一个只会偶尔调用os.getppid()的线程,如果返回值停止匹配从父进程传入的pid,则调用os._exit(). (这种方法可以移植到所有Unix,包括OS X,而prctl技巧是Linux特定的.)

在Windows上：在使用OpenProcess和os.waitpid的子代中生成一个线程.使用ctypes的例子：

from ctypes import WinDLL, WinError

from ctypes.wintypes import DWORD, BOOL, HANDLE

# Magic value from http://msdn.microsoft.com/en-us/library/ms684880.aspx

SYNCHRONIZE = 0x00100000

kernel32 = WinDLL("kernel32.dll")

kernel32.OpenProcess.argtypes = (DWORD, BOOL, DWORD)

kernel32.OpenProcess.restype = HANDLE

parent_handle = kernel32.OpenProcess(SYNCHRONIZE, False, parent_pid)

# Block until parent exits

os.waitpid(parent_handle, 0)

os._exit(0)

这样可以避免我提到的任务对象可能出现的问题.

如果你想要真的,真的确定,那么你可以结合所有这些解决方案.

希望有帮助！