1

我在瓶子网络服务器中有一个 Python 应用程序，它通过 Linux 平台上的 ctypes Python 模块访问 C 共享对象库。C so-lib 打开一个设备节点 ( /dev/myhwdev) 并针对设备的文件描述符声明一个 IOCTL 函数。虽然这是一个复杂的堆栈，但在我将瓶子应用程序包装在 Python 的 python-daemon 上下文中之前它工作得很好，如下所示：

# -*- 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";

只需注释掉该with daemonContext行（并更正缩进）就可以使该代码正常工作（即，提供正确的 JSON 结果）。但是，在 daemonContext 中，我的 userlib 中的打印语句显示我的设备节点的文件描述符已正确打开，但 ioctl 函数静默失败，错误代码为 -1。

关闭设备的文件描述符并重新打开它（在 userlib 代码或上述路由处理程序中）允许命令正常工作 - 一次。但是，守护进程和瓶服务器锁定并忽略所有进一步的 Web 请求。

建议？目前，我准备放弃守护程序模块，因为没有它一切正常。

谢谢！

4

1 回答 1

1

在准备这个问题时，答案对我来说变得很明显。

该userlib_grab_device_file_descriptor()函数称为 C 级 SO-lib 函数，它打开硬件设备节点的文件描述符，该文件描述符被传递给 userlib ioctl 函数。

python-daemon 在进入上下文时关闭所有文件句柄 - 包括硬件设备的继承文件描述符。userlib 仍然认为文件描述符是有效的。至少，它会在我的调试消息中将 FD 打印为整数 > 2。但是，用户库不知道，文件句柄确实已关闭，因此 IOCTL 会默默地失败。我希望 uclib 或内核提供了更好的错误消息。:(

无论如何，答案是将打开的文件句柄移动到守护进程上下文的内部，如下所示：

...
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";

我尝试使用 python-daemon 的files_preserve属性，但它适用于文件描述符编号，而不是文件名。因此，在打开 fd 之后，我的 userlib 必须将 fd 编号传递给守护进程，因此它可以在进入守护进程之前排除 fd。...我发现在守护进程中打开文件描述符更容易。:)

希望这对其他人有帮助。:)

于 2012-06-28T22:18:19.037 回答