"No child processes" when reading ldconfig on linux

Deadline
1

Hi,

I’m getting this weird error on our custom plugins when it runs on a linux node. When i run the following code on a linux slave

    import ctypes
    libc = ctypes.CDLL(ctypes.util.find_library('c'), use_errno=True)

I would end up with this error

Initialize: Error: IOError : (10, ‘No child processes’) (Python.Runtime.PythonException)
File"/home/rush/Thinkbox/Deadline10/slave/node29/plugins/5c51fbd08bee0c25f0f99534/SimplePlugin.py", line 88, in InitializeProcess
libc = ctypes.CDLL(ctypes.util.find_library(‘c’), use_errno=True)
File “/opt/Thinkbox/Deadline10/bin/python/lib/python2.7/ctypes/util.py”, line 242, in find_library
return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name))
File “/opt/Thinkbox/Deadline10/bin/python/lib/python2.7/ctypes/util.py”, line 235, in _findSoname_ldconfig
f.close()

This would run fine on windows slave,python terminal on the same linux slave and even the scripting api through deadline monitor. Only through a custom deadline plugins am i able to replicate this error.

On further investigation on the problematic file under python2.7/ctypes/util.py. I see that its attempting to close “f = os.popen(‘/sbin/ldconfig -p 2>/dev/null’)” but its failing since the process isn’t finish loading.

    import os

    f = os.popen('/sbin/ldconfig -p 2>/dev/null')
    # f = os.popen('ls -l')
    
    try:
        blah = f.read()
    finally:
        f.close()

I switched the command over something simplier “ls -l” and that was able to complete. This draws to my conclusion that os.popen isn’t waiting long enough to load the 692 entries in our Linux dynamic Linker before attempting to close, which is why its failing with a “No child processes” since it didn’t finish loading the command before attempting to close.

what I am confused about though, is why is this happening now? We used this command before on Deadline 7.2 without error and i diffed the two Util.py and found nothing different with that function. Only on deadline 10.0.20 we started encountering this error.

Thanks!
Johnny

2

Good investigating there!

It might be because we’re using a slightly newer Pyhton 2.7 than we did back then and this bug was introduced. In some research, the Internet feels that “subprocess.popen” is better than “os.popen”. I’m not sure what the best way is around this. On one hand, you could try an upgraded Python like 2.7.15.

I guess, what are you calling in libc and are there other ways to get there? Windows won’t have it, so I’m not sure what you’re using it for.

3

We dealt with this issue by checking for the deadline10 environment before attempting to call the function. I actually tested the subprocess.popen over the os.popen and it was able to work properly.