2016-04-08 11 views
2

私のサブプロセスの実行がハングすることがあるのを解明しようとしています。私は、特権ドロップしてコマンドを実行するために、次のコードを実行している:マルチプロセスでexecを掛ける

def safe_exec(q, uid, gid): 
    try: 
     os.setgroups([]) 
     os.setregid(gid, gid) 
     os.setreuid(uid, uid) 

     print("dropped") 
     res = subprocess.check_output(['nm', '-D', '/lib/x86_64-linux-gnu/libc.so.6']) 
     print("executed") 
     q.put(res) 
    except Exception as e: 
     q.put(e) 

if __name__ == "__main__": 
    nobody = pwd.getpwnam('nobody') 
    q = multiprocessing.Queue() 
    p = multiprocessing.Process(
      target=safe_exec, 
      args=(q, nobody.pw_uid, nobody.pw_gid)) 

    p.start() 
    p.join(10) 
    res = q.get(False) 
    if isinstance(res, Exception): 
     raise res 
    else: 
     print(res) 

ハングすべてのコマンドで発生しませんが、私は確実に私のマシン上でnm -D .../libc.so.6でそれを再現することができます。問題は、ハングがsafe_execの最後に発生していることです。プロセスがまだハングしているうちに、「落とした」と「実行した」の両方が表示されていることがわかります。

Straceは以下を示します(省略形)。子供が開始され、予想通りINITS:

48858 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9aa3eab9d0) = 48859 
48859 setgroups(0, [])     = 0 
48859 setregid(65534, 65534)   = 0 
48859 setreuid(65534, 65534)   = 0 
48859 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 6), ...}) = 0 
48859 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9aa3ec2000 
48859 write(1, "dropped\n", 8)   = 8 

親が、今では参加しようとして開始します。

48858 wait4(48859, <unfinished ...> 
... 
48858 wait4(48859, 0x7fffa52cc07c, WNOHANG, NULL) = 0 
48859 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 48860 

subprocess.check_output()終了し、 "実行" が報告されています

48859 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=48860, si_status=0, si_utime=0, si_stime=0} --- 
48859 write(1, "executed\n", 9)   = 9 

メインプロセスタイムアウトを増やし始め、ただ待っています。 select/wait4 10秒が経過するまでサイクルします。 safe_execまで

48858 wait4(48859, 0x7fffa52cc07c, WNOHANG, NULL) = 0 
48858 select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout) 
48858 wait4(48859, 0x7fffa52cc07c, WNOHANG, NULL) = 0 
48858 select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout) 
48858 wait4(48859, 0x7fffa52cc07c, WNOHANG, NULL) = 0 
48858 select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) 
48858 wait4(48859, 0x7fffa52cc07c, WNOHANG, NULL) = 0 
48858 select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) 
[ + many more ] 

は最終的にメインプロセスが.join(10)上断念した直後、終了:

48858 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=48859, si_status=0, si_utime=0, si_stime=0} --- 
48858 wait4(48859, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 48859 

そして、それはそれだ - 通常のプロセスの終了。この場合、私は何が間違っているのか分かりません。明らかに失敗するものはありません。

gdbで実行中のプロセスを見ると、親がjoin内部waitに貼り付ける:

#0 0x00007fde4486b6d3 in __select_nocancel() at ../sysdeps/unix/syscall-template.S:81 
#1 0x000000000062dbd6 in floatsleep (secs=0) at ../Modules/timemodule.c:948 
#2 0x000000000062c843 in time_sleep (self=0x0, args=(<float at remote 0x1e15620>,)) at ../Modules/timemodule.c:206 
#3 0x00000000004896f9 in PyCFunction_Call (func=<built-in function sleep>, arg=(<float at remote 0x1e15620>,), kw=0x0) at ../Objects/methodobject.c:81 
#4 0x000000000052ff77 in call_function (pp_stack=0x7fff39cdc9f0, oparg=1) at ../Python/ceval.c:4356 
#5 0x000000000052a7f7 in PyEval_EvalFrameEx (
    f=Frame 0x1f643d0, for file /usr/lib/python2.7/multiprocessing/forking.py, line 165, in wait (self=<Popen(returncode=None, pid=67389) at remote 0x7fde43a83ed0>, timeout=20, deadline=<float at remote 0x1e15558>, delay=<float at remote 0x1e15620>, res=None, remaining=<float at remote 0x1e154e0>), throwflag=0) at ../Python/ceval.c:2993 

や子供も参加確定を待っている:

#0 0x00007f96798520c9 in futex_abstimed_wait (cancel=true, private=<optimised out>, abstime=0x0, expected=0, futex=0x1c109c0) at sem_waitcommon.c:42 
#1 do_futex_wait ([email protected]=0x1c109c0, abstime=0x0) at sem_waitcommon.c:208 
#2 0x00007f9679852164 in __new_sem_wait_slow (sem=0x1c109c0, abstime=0x0) at sem_waitcommon.c:277 
#3 0x00007f967985220a in __new_sem_wait (sem=<optimised out>) at sem_wait.c:28 
#4 0x00000000005787f5 in PyThread_acquire_lock (lock=0x1c109c0, waitflag=1) at ../Python/thread_pthread.h:324 
#5 0x000000000062aa9f in lock_PyThread_acquire_lock (self=0x7f9679c21c70, args=()) at ../Modules/threadmodule.c:52 
#6 0x00000000004896f9 in PyCFunction_Call (func=<built-in method acquire of thread.lock object at remote 0x7f9679c21c70>, arg=(), kw=0x0) at ../Objects/methodobject.c:81 
#7 0x000000000052ff77 in call_function (pp_stack=0x7ffda823dce0, oparg=0) at ../Python/ceval.c:4356 
#8 0x000000000052a7f7 in PyEval_EvalFrameEx (
    f=Frame 0x1c107b0, for file /usr/lib/python2.7/threading.py, line 340, in wait (self=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x7f9679c21c20>, acquire=<built-in method acquire of thread.lock object at remote 0x7f9679c21c20>, _Condition__waiters=[<thread.lock at remote 0x7f9679c21c70>], release=<built-in method release of thread.lock object at remote 0x7f9679c21c20>) at remote 0x7f9676cec1b0>, timeout=None, waiter=<thread.lock at remote 0x7f9679c21c70>, saved_state=None), throwflag=0) 
    at ../Python/ceval.c:2993 

のpythonスタック内をその子は:

_Condition.wait 
Thread.join 
Queue._finalize_join 
Finalize.__call__ 

私はなぜそのプロセスが長い間ぶら下がっているのかについてのアイデアは控えてください。

コード

は、Python 2.7と3.4

+0

'Queue'オブジェクトに接続されているように見えます。あなたのものか、'マルチプロセス 'が背後で使っているものです。例えば。 'q.put(res)'は実行されますか? –

答えて

0

問題に実行されたことはキューに送られた小さな、または空の結果が正しく処理されたということでしたが、長い結果がありませんでしたし、プロセスが参加し、ブロッキングしました。

この問題は、参加する前にキューから結果を取得することで解決/回避されます。