Question

I have a Python application in the bottle web-server that accesses a C shared-object library via the ctypes Python module on a Linux platform. The C so-lib opens a device node (/dev/myhwdev) and asserts an IOCTL function against the device’s file descriptor. Although this is a complicated stack, it works great until I wrap the bottle app in Python’s python-daemon context, like so:

# -*- coding: utf-8 -*-
import daemon
import bottle
from bottle import run, route, request

from userlib_via_ctypes_module import *
userlib_grab_device_file_descriptor()

@route('/regread')
def show_regread():
    address = request.query.address or request.forms.address
    length = request.query.length or request.forms.length
    return {'results':assert_ioctl_via_userlib(address, length)}

daemonContext = daemon.DaemonContext(
    detach_process = False
    )
with daemonContext:
    try:
        run(host = '0.0.0.0', port = '80', debug = True)
    except:
        print "(E) Bottle web-service was stopped.\n";

Simply commenting out the with daemonContext line (and correcting indentation) allows this code to work correctly (i.e., serves the correct JSON result). However, within the daemonContext, print statements in my userlib show that the file-descriptor for my device node is opened correctly, but the ioctl function silently fails with an error code of -1.

Closing the device’s file-descriptor and reopening it (in either the userlib code or the above route handler) allow the command to work correctly – once. But, the daemon and bottle server lock up and ignore all further web requests.

Suggestions? Currently, I am ready to give up on the daemon module, since everything works fine with out it.

Thanks!

Answer 1

In preparing this question, the answer became obvious to me.

The userlib_grab_device_file_descriptor() function called a C-level, SO-lib function that opened the file-descriptor for the hardware device node, which was passed to the userlib ioctl function.

The python-daemon closes ALL file-handles upon entry of the context – including the inherited file-descriptor for the hardware device. The userlib still thought the file-descriptor was valid. At least, it would print the FD in my debug messages as an integer > 2. However, unbeknown to the userlib, the file-handle had indeed been closed, so the IOCTL would just fail silently. I wished there had been a better error message supplied by uclib or the kernel. 🙁

Anyway, the answer was to move the file-handle opening to the inside of the daemon context, like so:

...
with daemonContext:
    try:
        userlib_grab_device_file_descriptor()   # open fd here
        run(host = '0.0.0.0', port = '80', debug = True)
    except:
        print "(E) Bottle web-service was stopped.\n";

I tried using python-daemon’s files_preserve attribute, but it works on file-descriptor numbers, not filenames. Therefore, after opening the fd, my userlib would have to pass the fd number up to the daemon, so it could exclude the fd before entering the daemon. … I found it easier to open the file-descriptor inside the daemon. 🙂

Hope this helps someone else. 🙂