在 Python 的 subprocess.Popen
中,universal_newlines=True
参数用于指定以文本模式处理标准输入和输出。当设置为 True
时,标准输入和输出将被处理为文本而不是字节流。
具体来说,universal_newlines=True
参数会在以下情况下进行处理:
-
标准输入(stdin):如果你向子进程发送文本数据,Python 会将其编码为字节流并传递给子进程的标准输入。子进程会将这些字节流解码为文本。
-
标准输出(stdout)和标准错误(stderr):子进程的输出会被解码为文本,而不是字节流。这样在 Python 中可以更方便地处理输出的文本数据。
总的来说,universal_newlines=True
的作用是在 Python 中使用文本模式处理标准输入、输出和错误流,使得处理文本数据更加方便。
下面是一个示例代码,演示了如何使用 universal_newlines=True
参数来启用文本模式处理:
import subprocess
with open(fileName, "w") as logfile:
proc1 = subprocess.Popen(
["./test"],
cwd=testPath,
stdin=subprocess.PIPE,
stdout=logfile,
stderr=subprocess.PIPE,
bufsize=1, # 行缓冲模式
universal_newlines=True # 使用文本模式
)
# 发送 SIGINT 信号给 proc1, 相当于Ctrl + C
proc1.send_signal(signal.SIGINT) # proc1.poll() 值 None
print(proc1.pid)
# 关闭接收数据的程序。 直接终止子进程,可能导致子进程无法完成清理工作。
if proc1.poll() is None:
proc1.terminate()
在Python的subprocess.Popen
中,可以通过将bufsize
参数设置为0来选择无缓冲的I/O。这意味着输入和输出都将被立即处理,而不会被缓冲。
以下是一个简单的示例,演示如何使用bufsize=0
来执行子进程:
import subprocess
# 执行命令并将输出重定向到文件中
with open("output.log", "w") as logfile:
proc = subprocess.Popen(
["echo", "Hello, World!"],
stdout=logfile,
stderr=subprocess.PIPE,
bufsize=0 # 选择无缓冲模式
)
# 等待进程结束
stdout, stderr = proc.communicate()
在这个示例中,我们将bufsize
参数设置为0,以选择无缓冲模式。这意味着子进程的输出将会立即写入到output.log
文件中。
需要注意的是,虽然选择无缓冲模式可以确保数据立即被处理,但可能会带来性能上的开销。因此,在实际使用时,需要权衡是否真的需要无缓冲模式
在Python的subprocess.Popen
中,将bufsize
参数设置为1可以启用行缓冲模式,这样输出会在每行结束时被写入文件。下面是一个示例代码,演示如何使用bufsize=1
执行子进程:
import subprocess
# 执行命令并将输出重定向到文件中
with open("output.log", "w") as logfile:
proc = subprocess.Popen(
["echo", "Line 1\nLine 2\nLine 3"],
stdout=logfile,
stderr=subprocess.PIPE,
bufsize=1 # 启用行缓冲模式
)
# 等待进程结束
stdout, stderr = proc.communicate()
在这个示例中,我们将bufsize
参数设置为1,以启用行缓冲模式。这意味着子进程的输出会在每行结束时被写入到output.log
文件中。这样可以确保每行文本都会即时地写入文件,而不是等到缓冲区满或者换行符出现才写入。
使用行缓冲模式可以在一定程度上提高实时性,特别是处理实时日志等情况时比较有用。
在 Python 的 subprocess.Popen
中,universal_newlines=True
参数用于指定以文本模式处理标准输入和输出。当设置为 True
时,标准输入和输出将被处理为文本而不是字节流。
具体来说,universal_newlines=True
参数会在以下情况下进行处理:
-
标准输入(stdin):如果你向子进程发送文本数据,Python 会将其编码为字节流并传递给子进程的标准输入。子进程会将这些字节流解码为文本。
-
标准输出(stdout)和标准错误(stderr):子进程的输出会被解码为文本,而不是字节流。这样在 Python 中可以更方便地处理输出的文本数据。
总的来说,universal_newlines=True
的作用是在 Python 中使用文本模式处理标准输入、输出和错误流,使得处理文本数据更加方便。
下面是一个示例代码,演示了如何使用 universal_newlines=True
参数来启用文本模式处理:
import subprocess # 执行命令并将输出重定向到文件中 with open("output.log", "w") as logfile: proc = subprocess.Popen( ["echo", "Hello, World!"], stdout=logfile, stderr=subprocess.PIPE, bufsize=1, universal_newlines=True # 启用文本模式处理 ) # 等待进程结束 stdout, stderr = proc.communicate()
在这个示例中,输出会以文本形式写入到output.log
文件中,而不是字节流形式。
proc1.send_signal(signal.SIGINT)
退出进程失败原因
在 Python 中,subprocess.Popen
用于启动子进程,并通过管道与其进行通信。你提到的 proc1.send_signal(signal.SIGINT)
是用来向子进程发送 SIGINT
信号(通常是 Ctrl+C),以尝试优雅地停止它。
如果 proc1.send_signal(signal.SIGINT)
调用后,子进程没有退出,并且 proc1.poll()
返回 None
,这意味着子进程还在运行,并且没有因为接收到 SIGINT
信号而退出。可能的原因包括:
-
子进程没有正确处理
SIGINT
:如果子进程没有安装信号处理器来响应SIGINT
信号,或者其信号处理器没有正确实现退出逻辑,那么它可能不会响应这个信号。 -
子进程正在执行阻塞操作:如果子进程正在执行一个阻塞的 I/O 操作或长时间运行的任务,并且没有检查信号,那么它可能不会立即响应
SIGINT
。 -
子进程可能是一个 shell:当你使用
shell=True
时,实际上是在启动一个 shell 来执行你的命令。这个 shell 本身可能会接收到SIGINT
信号,但它不会将信号传递给其启动的程序(在这个例子中是unbuffer ./test_yusur_futures_market_all
)。 -
子进程权限问题:有时候,子进程可能因为权限问题而无法正常接收到或处理信号。
-
子进程已经死亡但状态未更新:极少数情况下,子进程可能已经死亡,但 Python 的
Popen
对象的状态还没有更新。这通常是因为 Python 与子进程之间的通信存在问题。
要解决这个问题,你可以尝试以下方法:
-
确保子进程正确处理
SIGINT
:检查子进程的代码,确保它有一个信号处理器来处理SIGINT
,并优雅地退出。 -
使用
SIGTERM
而不是SIGINT
:有时,SIGTERM
比SIGINT
更适合用来请求程序退出。你可以尝试使用proc1.send_signal(signal.SIGTERM)
。 -
不使用
shell=True
:如果可能,避免使用shell=True
,直接传递命令和参数列表给Popen
。这可以减少因为 shell 导致的复杂性和不确定性。 -
检查子进程的输出和错误:通过
proc1.stdout
和proc1.stderr
读取子进程的输出和错误,看看是否有任何有用的信息。 -
使用
proc1.terminate()
或proc1.kill()
:如果send_signal
不起作用,你可以尝试使用proc1.terminate()
(发送SIGTERM
)或proc1.kill()
(发送SIGKILL
)来强制结束子进程。 -
检查子进程的 PID:通过
proc1.pid
获取子进程的 PID,并使用外部工具(如kill
命令)尝试结束它。
最后,确保你的 Python 脚本有足够的权限来管理子进程,并且子进程本身没有遇到任何阻止它正常退出的问题。
proc1.pid 进程和top查看结果不一致
如果你发现 proc1.pid
显示的进程 ID 与使用 top
命令查看的结果不一致,这通常意味着以下几点之一:
-
进程已经结束:
proc1.pid
显示的进程 ID 可能属于一个已经结束的进程。如果Popen
对象没有正确更新其状态,或者你的脚本在进程结束后仍然保留了对Popen
对象的引用,那么proc1.pid
可能会显示一个已经不存在的进程的 ID。 -
进程 ID 被重用:在 Linux 系统中,进程 ID(PID)是被系统循环使用的。当一个进程结束时,它的 PID 可能会被分配给后续启动的新进程。如果你的脚本在进程结束后立即检查 PID,并且恰好有一个新进程被分配了相同的 PID,那么你会看到不一致的结果。
-
查看的不是同一个进程:有可能你的
top
命令显示的是另一个与你的脚本无关的进程。确保你在top
中查找的是正确的进程名或命令行。 -
权限问题:在某些情况下,如果你的脚本或
top
命令运行的用户没有足够的权限查看所有进程,可能会导致你看到的进程列表不完整或不一致。
为了解决这个问题,你可以尝试以下步骤:
-
检查进程状态:使用
os.kill(proc1.pid, 0)
来检查进程是否还存在。如果这个调用没有抛出OSError
,那么进程仍然存在。如果抛出OSError: [Errno 3] No such process
,那么进程已经不存在了。 -
更新 Popen 对象状态:尝试调用
proc1.poll()
来获取进程的退出状态。如果返回None
,则进程仍在运行;如果返回一个整数,则进程已经结束,该整数是进程的退出码。 -
检查 Popen 对象:确保你没有在脚本的其他地方意外地修改了
proc1
对象或它的pid
属性。 -
使用 ps 命令:你可以使用
ps
命令来查找具有特定 PID 的进程。例如,ps -p <PID>
会显示与给定 PID 相关的进程信息。这可以帮助你确认 PID 是否仍然有效。 -
检查 top 的输出:确保你在
top
命令的输出中查找的是正确的进程名或命令行。有时候,相似名称的进程可能会混淆你的判断。 -
考虑使用其他方法:如果你需要持续监控和管理子进程,可能需要考虑使用更高级的进程管理工具或库,如
psutil
,它提供了更丰富的进程管理功能。
最后,确保你的脚本逻辑是正确的,并且在处理子进程时考虑了所有可能的边缘情况。
shell=True 和 shell=False区别
在Python的subprocess
模块中,shell
参数用于指定是否使用shell来执行命令。shell=True
和shell=False
之间存在几个关键的区别:
- 命令执行方式:
- 当
shell=True
时,subprocess
会启动一个shell(例如bash),然后将命令字符串作为shell命令执行。这意味着你可以在命令字符串中使用shell的特性,如管道(|
)、变量扩展、命令替换等。 - 当
shell=False
时,subprocess
直接将命令列表中的第一个元素作为要执行的程序,并将剩余的元素作为该程序的参数。这种方式不会使用shell的特性,而是直接调用程序。
- 当
- 安全性:
- 使用
shell=True
可能会引入安全风险,特别是当命令字符串中包含用户输入时。恶意用户可能会利用shell的特性来执行未授权的命令。因此,在涉及用户输入或不受信任的数据时,应尽量避免使用shell=True
。 shell=False
通常更安全,因为它不会解释命令字符串中的shell特性。但是,仍然需要注意正确处理用户输入和参数,以防止其他类型的攻击(如命令注入)。
- 使用
- 性能:
- 使用
shell=True
可能会比shell=False
慢一些,因为启动一个shell并执行命令需要额外的开销。
- 使用
- 错误处理:
- 当
shell=True
时,命令的输出(包括标准输出和标准错误)通常会被合并在一起,这可能使得解析和分离输出变得更加困难。 - 使用
shell=False
时,你可以分别获取标准输出和标准错误,这有助于更好地处理命令执行过程中可能出现的错误。
- 当
下面是一个简单的例子来说明这两种方式的区别:
import subprocess
# 使用 shell=True
result = subprocess.run("echo Hello; echo World", shell=True, stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8')) # 输出: Hello\nWorld\n
# 使用 shell=False
# 注意这里需要使用一个列表来传递命令和参数
result = subprocess.run(["echo", "Hello"], stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8')) # 输出: Hello\n
在大多数情况下,如果可能的话,建议使用shell=False
来避免潜在的安全风险和提高性能。如果你确实需要使用shell的特性,确保你充分理解相关的安全风险,并采取适当的措施来减少这些风险。
env参数
dir = '/home'
# 设置环境变量
env = {'LD_LIBRARY_PATH': '../../*.so'}
# 命令及其参数
command = ['./test']
# 使用 subprocess.Popen 启动进程
market_proc1 = subprocess.Popen(command, cwd=dir, stdin=subprocess.PIPE, stdout=logfile, stderr=subprocess.PIPE, bufsize=1, universal_newlines=True, env=env)
在 subprocess.Popen
中,env
参数用于设置子进程的环境变量。它接受一个字典作为值,其中字典的键是环境变量的名称,字典的值是相应环境变量的值。
例如:创建了一个名为 env
的字典,并将 'LD_LIBRARY_PATH'
作为键,'../../*.so'
作为相应的值。然后,我们将这个字典作为 env=env
参数传递给 subprocess.Popen
。
通过这样做,我们可以确保在启动子进程时,子进程将具有正确的 LD_LIBRARY_PATH
环境变量设置。这对于某些程序可能依赖于特定的库文件路径非常重要。
总之,env=env
是用于将环境变量字典传递给 subprocess.Popen
函数的方法。
无缓冲写入logfile
import subprocess
import os
import signal
import time
from datetime import datetime
import glob
import sys
# 获取kill次数
count = sys.argv[1]
dirV = "/home/test/v1.0.1"
dirData = os.getcwd() # 当前路径
def mul_process():
current_time = datetime.now()
uniq = f"{current_time.year}{current_time.month}{current_time.day}_{current_time.hour}{current_time.minute}{current_time.second}"
print(uniq)
# 启动 test 进程并获取其输出
try:
# 使用 subprocess 执行启动 test 进程的命令,并捕获输出
with open(f"{dirData}/{uniq}_marketAll.log", "w") as logfile:
proc1 = subprocess.Popen(["stdbuf", "-o0", "./test"], cwd=dirV, stdin=subprocess.PIPE,
stdout=logfile, stderr=subprocess.STDOUT, bufsize=0,universal_newlines=True)
# process = subprocess.Popen(test_command, stdout=subprocess.PIPE, shell=True)
print("test process started.")
# 等待一段时间确保 行情数据 进程已经启动
time.sleep(1)
logfile.flush()
# 获取 test 进程的进程 ID(PID)
test_pid = proc1.pid
print(f"test process ID: {test_pid}")
# for _ in range(10):
# time.sleep(1)
# logfile.flush()
#
# # 最后一次刷新和关闭文件
# logfile.flush()
# os.fsync(logfile.fileno()) # 强制将文件内容写入磁盘
# print("Final flush and sync done.")
try:
for _ in range(10):
time.sleep(1)
# logfile.write("Logging some data...\n")
logfile.flush()
os.fsync(logfile.fileno()) # Force write to disk
except Exception as e:
print(f"Exception occurred: {e}")
# 杀死 test 进程
#os.kill(test_pid, signal.SIGTERM)
os.system(f"kill -9 {test_pid}")
print("test process killed.")
# 查找最新的行情数据bin文件,移动到当前文件夹
except Exception as e:
print(f"Error: {e}")
finally:
# 可以在这里进行清理操作,比如关闭打开的文件描述符等
pass
for i in range(int(count)):
print(f"第{i+1}次kill")
mul_process()
问题:
子进程的 stdout
重定向到logfile,设置了 universal_newlines=True
和 bufsize=0
,通常应该确保输出能够即时地写入到文件中。然而,缓冲区的内容没有即时写入到 logfile
可能原因:
-
子进程输出缓冲:
子进程(./test
)本身可能在其内部有输出缓冲。可能不会在每次打印后立即刷新其缓冲区到stdout
。这种情况下,子进程内部的缓冲行为是无法通过 Python 脚本直接控制的。 -
操作系统和文件系统的延迟:
虽然使用了os.fsync(logfile.fileno())
来强制将文件内容写入磁盘,但操作系统的文件系统缓存仍然可能导致你看到的文件内容与实际写入磁盘的内容之间存在延迟。 -
子进程异常终止:
如果子进程在写入任何内容之前就异常终止了,那么你可能看不到任何输出。
解决方案:
1.检查子进程内部:
查看 ./test
的源代码,确认在每次输出后都刷新了 stdout
。如果没有,考虑修改它或使用如 fflush(stdout)
(如果它是用 C/C++ 写的)来强制刷新。
2.使用 stdbuf
:
如果你的系统支持 stdbuf
(通常在 GNU/Linux 上可用),你可以在启动子进程时使用它来修改标准输出的缓冲行为。例如:
proc1 = subprocess.Popen(["stdbuf", "-o0", "./test"], cwd=dirV, stdin=subprocess.PIPE,
stdout=logfile, stderr=subprocess.STDOUT, bufsize=0,universal_newlines=True)
这里的 -o0
选项告诉 stdbuf
将 stdout
的缓冲设置为无缓冲。
3. 增加日志检查:
在子进程中增加额外的日志输出来验证它在何处停止了执行,或者在何时执行了某些关键操作。
4.确认子进程仍在运行:
在尝试杀死子进程之前,确认它是否仍在运行。你可以通过检查 proc1.poll()
的返回值来确认子进程是否已结束。
5.使用更可靠的进程终止方式:
尽量使用 proc1.terminate()
而不是 os.system(f"kill -9 {test_pid}")
来终止子进程。terminate()
会发送 SIGTERM
信号,给子进程一个清理的机会。如果子进程没有响应,再考虑使用 kill()
方法发送 SIGKILL
。