如何让2个应用程序在linux中相互运行?

时间:2013-05-23 10:43:46

标签: c++ linux shell process nohup

情况如下:

我们有一个主应用程序和一个观察程序应用程序。 它们都是c ++应用程序。它们都使用守护进程(1,0)功能。

Watcher检查主应用程序是否正在运行,是否发现主进程不存在(崩溃)或主要进程没有响应(应用程序通过TCP互相通话,以及它是如何知道它是否挂起)然后运行主要或重新开始。

现在,用户可以更改连接的TCP设置,并通过主应用程序完成。更改后,必须重新启动观察程序才能加载新配置。这是从主应用程序完成的。

实际上,它运作正常 1.启动时主应用程序将杀死现有的观察程序进程并再次运行它。 [这是正确的]
2. Watcher应用程序杀死主要并再次运行它。 [这是正确的]

BUT

  1. 如果我运行Main,它反过来启动Watcher,
  2. 然后杀死Main,让Watcher独自一人。
  3. Watcher发现没有Main了,所以它再次启动它。
  4. 主要重新开始,杀死观察者并试图重新开始......
  5. 并且在这一点上,发生了某种不存在的情况。它启动了观察者(我可以看到通过netstat命令获取TCP端口),但是没有名为watcher的进程。
  6. 如果netstat通常显示tcp 0 0 IP:TCP_PORT LISTEN Watcher,现在显示tcp 0 0 IP:TCP_PORT LISTEN Main

    就好像观察者在那里,但在主要过程中。

    我使用脚本来运行应用程序。 Watcher使用此

    #!/bin/sh
    killall -9 Main
    ./Main
    

    并像system("./runMain.sh&");

    一样运行

    主要使用此

    #!/bin/sh
    killall -9 Watcher
    ./Watcher
    

    并像system("./runWatcher.sh&");

    一样运行

    我做错了什么?我如何运行它们以便在需要时可以相互重新启动并始终在单独的进程中启动?

    到目前为止,我还尝试使用nohup运行脚本,结果是一样的。

    编辑1:

    注意:这里的数字只是为了清晰起见。实际上,PID当然不是1。

    1. 我运行Main。 netstat告诉我:

      tcp 0 0 192.168.0.1:7000 LISTEN(PID 1)主要
      tcp 0 0 192.168.0.1:7001 LISTEN(PID 1)Main

    2. Main使用脚本启动Watcher。现在netstat告诉我:

      tcp 0 0 192.168.0.1:7000 LISTEN(PID 1)主要
      tcp 0 0 192.168.0.1:7001 LISTEN(PID 1)主要
      tcp 0 0 192.168.0.1:8000 LISTEN(PID 2)观察者

    3. 现在,我通过killall -9 Main手动杀死Main。现在netstat告诉我:

      tcp 0 0 192.168.0.1:7000 LISTEN(PID 2)观察员
      tcp 0 0 192.168.0.1:7001 LISTEN(PID 2)观察员
      tcp 0 0 192.168.0.1:8000 LISTEN(PID 2)观察者

      注意现在谁拥有监听套接字的变化?这是怎么发生的?

    4. Watcher发现Main已经消失,所以它使用脚本文件启动它。

    5. Main在启动时杀死Watcher。 Netstat显示:

      tcp 0 0 192.168.0.1:7000 LISTEN(PID 3)主要
      tcp 0 0 192.168.0.1:7001 LISTEN(PID 3)主要
      tcp 0 0 192.168.0.1:8000 LISTEN(PID 3)Main

    6. 就是这样。 Watcher再也不会跑了。 我试图在Eclipse中进行调试,Watcher崩溃而没有在daemon(1,0)行上抛出任何东西。

1 个答案:

答案 0 :(得分:0)

如何使用自定义信号(甚至在另一个端口上侦听管理命令)?使用kill -9正在使用进程树,例如子进程获得对父资源(端口等)的控制

然后,最重要的是,当Watcher启动Main进程时,为什么它会假设Watcher的运行实例应该被杀死?一个原因是Watcher是Main的父母,所以我可以看出这可能会带来麻烦。

归结为需要两个进程在'kill'信号之外进行通信。

使用信号量或其他一些操作系统级别的通信机制来协调两者之间的连接。