python,运行命令行服务器 - 它们没有正确监听

发布于 2024-09-03 07:53:17 字数 810 浏览 6 评论 0原文

我尝试使用 pexpect (甚至直接使用 subprocess.Popen())通过命令行启动服务器应用程序(在 erlang 中,打开端口并侦听 http 请求)。

应用程序启动正常,日志(通过 pexpect)正常到屏幕,我也可以通过命令行与它交互...
问题是服务器不会监听传入的请求。当我通过在命令行中键入命令手动启动该应用程序时,该应用程序会进行侦听。使用 subprocess/pexpect 会阻止应用程序以某种方式监听...
当我手动启动它时,“netstat -tlp”将应用程序显示为正在监听,当我通过 python (subprocess/pexpect) 启动它时,netstat 不会注册该应用程序...

我有一种感觉,它与环境有关, python forks 的方式等等。 有什么想法吗?

谢谢你的

基本例子: 注意:
“-pz” - 仅将 ./ebin 广告到 erl VM 的模块路径、库搜索路径
“-run” - 运行 moduleName,不带任何参数。

command_str = "erl -pz ./ebin -run moduleName"  
child = pexpect.spawn(command_str)  
child.interact() # Give control of the child to the user

所有这些东西都能正常工作,这很奇怪。我在我的代码中记录了日志,并且所有日志消息都按其应有的方式输出。即使我通过 bash 脚本启动其进程,服务器也不会监听,所以我不认为是 python 代码导致了它(这就是为什么我有一种感觉,它与新操作系统进程的启动方式有关)。

Im attempting to start a server app (in erlang, opens ports and listens for http requests) via the command line using pexpect (or even directly using subprocess.Popen()).

the app starts fine, logs (via pexpect) to the screen fine, I can interact with it as well via command line...
the issue is that the servers wont listen for incoming requests. The app listens when I start it up manually, by typing commands in the command line. using subprocess/pexpect stops the app from listening somehow...
when I start it manually "netstat -tlp" displays the app as listening, when I start it via python (subprocess/pexpect) netstat does not register the app...

I have a feeling it has something to do with the environemnt, the way python forks things, etc.
Any ideas?

thank you

basic example:
note:
"-pz" - just ads ./ebin to the modules path for the erl VM, library search path
"-run" - runs moduleName, without any parameters.

command_str = "erl -pz ./ebin -run moduleName"  
child = pexpect.spawn(command_str)  
child.interact() # Give control of the child to the user

all of this stuff works correctly, which is strange. I have logging inside my code and all the log messages output as they should. the server wouldnt listen even if I started up its process via a bash script, so I dont think its the python code thats causing it (thats why I have a feeling that its something regarding the way the new OS process is started).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

仙气飘飘 2024-09-10 07:53:17

这可能与命令行参数传递给子进程的方式有关。

没有更具体的代码,我不能肯定地说,但我在 sshsplit 上工作时遇到了这个问题( https://launchpad. net/sshsplit

要正确传递参数(在本例中为“ssh -ND 3000”),您应该使用如下内容:

openargs = ["ssh", "-ND", "3000"]
print "Launching %s" %(" ".join(openargs))
p = subprocess.Popen(openargs, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

这不仅可以让您准确地看到您正在启动的命令,而且应该正确传递可执行文件的值。虽然在没有看到一些代码的情况下我不能肯定地说,但这似乎是最有可能的失败原因(也可能是程序需要特定的工作目录或配置文件?)。

It could be to do with the way that command line arguments are passed to the subprocess.

Without more specific code, I can't say for sure, but I had this problem working on sshsplit ( https://launchpad.net/sshsplit )

To pass arguments correctly (in this example "ssh -ND 3000"), you should use something like this:

openargs = ["ssh", "-ND", "3000"]
print "Launching %s" %(" ".join(openargs))
p = subprocess.Popen(openargs, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

This will not only allow you to see exactly what command you are launching, but should correctly pass the values to the executable. Although I can't say for sure without seeing some code, this seems the most likely cause of failure (could it also be that the program requires a specific working directory, or configuration file?).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文