从另一个 C 进程创建一个新的独立进程
存在两个 C 可执行文件 A 和 B。 A 和 B 通过套接字相互通信。
B 可以独立启动,也可以通过 A 启动。
如果先启动 B,再启动 A,则 A 和 B 都能正常启动,不会出现问题。 即使重新启动A,也没有问题。
如果B通过A启动,则A和B正常启动。 但这里通信端口是绑定到A和B的。这里,如果A重启,那么A启动失败。
由于B是通过A启动的,所以进程A是进程B的父进程。
那么,有什么办法可以让进程B独立于进程A启动呢?
我们尝试使用 fork,但是当我们尝试启动 exe 时使用 fork,会启动两个进程而不是一个。
Two C executables A and B exist.
A and B communicate to each other through a socket.
B can be started independently or through A.
If B is started first and A is started next, then A and B start properly without issues.
Even if A is restarted, then there are no issues.If B is started through A, then A and B starts properly. But here the communication port is bound to both A and B. Here, if A is restarted, then A fails to start.
Since B is started through A, Process A is the parent of Process B.
So, is there any means by which the Process B can be started independently from Process A?
We tried using fork, but with fork when we try to start the exe, two process is being started instead of one.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您是否尝试过使用“包装器”可执行文件分叉两次(一次用于 A,一次用于 B),然后自行终止? 这将使 A 和 B 作为单独的进程存活,然后由 init 进程继承,并且应该可以安全地重新启动。
Have you tried using a 'wrapper' executable that forks off twice - once for A and once for B - and then kills itself? This would have A and B alive as separate processes that are then inherited by the init process, and should be safely restartable.
您确定正确检查了 fork() 的返回值吗?
喜欢:
Are you sure you are checking correctly the return value of fork()?
Like:
您使用的是 Unix 域套接字还是常规网络套接字?
哪个进程(A 或 B)正在侦听套接字(被动打开),哪个正在执行主动打开?
当您决定 A 应该运行 B 时,代码如何确定这是必要的?
您是否在 fork 和 exec 之前打开套接字?
从给出的信息中我的印象是:
但我很容易被误解。
我想知道您是否遇到问题,因为 A 在 fork 和 exec B 之前已经创建了活动套接字,因此当 A 终止时,套接字的活动端没有完全关闭,因为 B 有一个打开的套接字副本可供写入A. 当你fork时,子进程应该在执行另一个进程之前清理不需要的文件描述符(例如套接字)。
Are you using a Unix domain socket or a regular network socket?
Which of the processes, A or B, is listening on the socket (passive open), and which is doing the active open?
When you decide that A should run B, how does the code determine that this is necessary?
Are you opening the socket before you fork and exec?
My impression from the information given is:
But I could easily be mistaken.
I wonder if you run into issues because A has already created the active socket before you fork and exec B, so the active end of the socket is not closed cleanly when A terminates because B has a copy of the socket open for writing as well as A. When you fork, the child process should clean up unneeded file descriptors (such as sockets) before executing another process.