Sử dụng subprocess.Popen cho quá trình với đầu ra lớn

Question

Tôi có một số mã Python thực thi một ứng dụng bên ngoài hoạt động tốt khi ứng dụng có một lượng nhỏ đầu ra, nhưng bị treo khi có rất nhiều. Mã của tôi trông giống như:

p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) 
errcode = p.wait() 
retval = p.stdout.read() 
errmess = p.stderr.read() 
if errcode: 
    log.error('cmd failed <%s>: %s' % (errcode,errmess)) 

Có ý kiến ​​trong tài liệu dường như cho biết vấn đề tiềm ẩn. Dưới chờ đợi, có:

Cảnh báo: Đây sẽ bế tắc nếu quá trình con tạo ra đủ sản lượng để một ống stdout hoặc stderr như vậy mà nó khối chờ đợi bộ đệm ống OS để chấp nhận dữ liệu hơn. Sử dụng communicate() để tránh điều đó.

dù dưới giao tiếp, tôi thấy:

Lưu ý Các dữ liệu đọc được đệm trong bộ nhớ, do đó, không sử dụng phương pháp này nếu kích thước dữ liệu quá lớn hoặc không giới hạn.

Vì vậy, không rõ ràng với tôi rằng tôi nên sử dụng một trong những điều này nếu tôi có một lượng lớn dữ liệu. Họ không chỉ ra phương pháp nào tôi nên sử dụng trong trường hợp đó.

Tôi cần giá trị trả lại từ lệnh exec và phân tích cú pháp và sử dụng cả hai stdout và stderr.

Vì vậy, một phương pháp tương đương trong Python để thực thi một ứng dụng bên ngoài sẽ có đầu ra lớn là gì?

Answer 1

Bạn đang chặn việc đọc tới hai tệp; nhu cầu đầu tiên cần hoàn thành trước khi bắt đầu lần thứ hai. Nếu ứng dụng viết rất nhiều đến stderr, và không có gì để stdout, sau đó quá trình của bạn sẽ ngồi chờ đợi dữ liệu trên stdout mà không đến, trong khi chương trình bạn đang ngồi ngồi chờ đợi cho những thứ nó đã viết để stderr để được đọc (mà nó sẽ không bao giờ - vì bạn đang đợi stdout).

Có một số cách bạn có thể khắc phục điều này.

Cách đơn giản nhất là không chặn stderr; rời khỏi stderr=None. Lỗi sẽ được xuất trực tiếp đến stderr. Bạn không thể chặn chúng và hiển thị chúng như là một phần của thông điệp của riêng bạn. Đối với các công cụ dòng lệnh, điều này thường là OK. Đối với các ứng dụng khác, nó có thể là một vấn đề.

Một cách tiếp cận đơn giản khác là chuyển hướng stderr đến stdout, vì vậy bạn chỉ có một tệp đến: đặt stderr=STDOUT. Điều này có nghĩa là bạn không thể phân biệt đầu ra thường xuyên từ đầu ra lỗi. Điều này có thể hoặc có thể không được chấp nhận, tùy thuộc vào cách ứng dụng ghi đầu ra.

Cách xử lý hoàn chỉnh và phức tạp này là select (http://docs.python.org/library/select.html). Điều này cho phép bạn đọc theo cách không chặn: bạn nhận dữ liệu bất cứ khi nào dữ liệu xuất hiện trên stdout hoặc stderr. Tôi chỉ đề nghị điều này nếu nó thực sự cần thiết.Điều này có thể không hoạt động trong Windows.

Answer 2

Rất nhiều đầu ra là chủ quan nên hơi khó để đưa ra đề xuất. Nếu số lượng đầu ra là thực sự là lớn thì bạn có thể không muốn lấy tất cả chỉ bằng một lệnh gọi đọc(). Bạn có thể muốn thử viết đầu ra vào một tệp và sau đó kéo dữ liệu theo từng bước như vậy:

f=file('data.out','w') 
p = subprocess.Popen(cmd, shell=True, stdout=f, stderr=subprocess.PIPE) 
errcode = p.wait() 
f.close() 
if errcode: 
    errmess = p.stderr.read() 
    log.error('cmd failed <%s>: %s' % (errcode,errmess)) 
for line in file('data.out'): 
    #do something 

Answer 3

Bạn có thể thử giao tiếp và xem cách đó giải quyết được sự cố của bạn. Nếu không, tôi sẽ chuyển hướng đầu ra sang một tệp tạm thời.

Answer 4

Glenn Maynard là đúng trong nhận xét của mình về deadlocks. Tuy nhiên, cách tốt nhất để giải quyết vấn đề này là tạo hai chủ đề, một cho stdout và một cho stderr, đọc các luồng tương ứng cho đến khi kiệt sức và làm bất cứ điều gì bạn cần với đầu ra.

Đề xuất sử dụng tệp tạm thời có thể hoặc có thể không hoạt động cho bạn tùy thuộc vào kích thước đầu ra, v.v. và bạn có cần xử lý đầu ra của tiến trình con khi nó được tạo ra hay không.

Như Heikki Toivonen đã đề xuất, bạn nên xem phương thức communicate. Tuy nhiên, điều này đệm stdout/stderr của subprocess trong bộ nhớ và bạn nhận được những trở về từ cuộc gọi communicate - điều này không lý tưởng cho một số kịch bản. Nhưng nguồn của phương thức giao tiếp đáng xem.

Một ví dụ khác là trong một gói tôi duy trì, python-gnupg, nơi gpg thực thi được sinh ra qua subprocess để làm việc nặng nhọc, và wrapper Python sinh ra các luồng để đọc stdout và stderr gpg và tiêu thụ chúng như dữ liệu được tạo ra bởi gpg . Bạn cũng có thể nhận được một số ý tưởng bằng cách nhìn vào nguồn ở đó. Dữ liệu do gpg tạo ra cho cả stdout và stderr có thể khá lớn, trong trường hợp chung.

Answer 5

Tôi cũng gặp vấn đề tương tự. Nếu bạn phải xử lý một đầu ra lớn, một lựa chọn tốt khác có thể là sử dụng một tệp cho stdout và stderr, và chuyển các tệp đó cho mỗi tham số.

Kiểm tra mô-đun tempfile trong python: https://docs.python.org/2/library/tempfile.html.

Something như thế này có thể làm việc

out = tempfile.NamedTemporaryFile(delete=False) 

Sau đó, bạn sẽ làm gì:

Popen(... stdout=out,...) 

Sau đó, bạn có thể đọc các tập tin, và xóa nó sau này.

Answer 6

Reading stdout và stderr một cách độc lập với sản lượng rất lớn (ví dụ, rất nhiều MB) sử dụng select:

import subprocess, select 

proc = subprocess.Popen(cmd, bufsize=8192, shell=False, \ 
    stdout=subprocess.PIPE, stderr=subprocess.PIPE) 

with open(outpath, "wb") as outf: 
    dataend = False 
    while (proc.returncode is None) or (not dataend): 
     proc.poll() 
     dataend = False 

     ready = select.select([proc.stdout, proc.stderr], [], [], 1.0) 

     if proc.stderr in ready[0]: 
      data = proc.stderr.read(1024) 
      if len(data) > 0: 
       handle_stderr_data(data) 

     if proc.stdout in ready[0]: 
      data = proc.stdout.read(1024) 
      if len(data) == 0: # Read of zero bytes means EOF 
       dataend = True 
      else: 
       outf.write(data)