我怎么想都必须用一个死循环来实现：在一个无限循环内，每隔一段时间就去检测指定的进程是不是存在。
死循环肯定是不行的，那我该怎么办？
望高人指教！
14 个解决方案
#1
把它写到/etc/inittab中
如：
ME0:2345:respawn:/usr/local/sbin/tcserver >/dev/null 2>/tmp/stderr.tcserver
如：
ME0:2345:respawn:/usr/local/sbin/tcserver >/dev/null 2>/tmp/stderr.tcserver
#2
fork，然后wait.
fork出来的进程去做事情，死了以后父进程的wait会返回，你检查一下子进程的死亡原因，然后决定是否重新fork
fork出来的进程去做事情，死了以后父进程的wait会返回，你检查一下子进程的死亡原因，然后决定是否重新fork
#3
其实我是想在c程序里实现这个功能，因为我在重启进程时还要做一些日志记录的工作，所以光用写到inittab中的方法好像难以实现。
#4
我可能还要在程序里实现定时扫描某个文件的功能，不知道怎么实现?又要死循环？
#5
支持fork+wait这种方法。
#6
写shell去判断进程是否存在，不在就重新运行。
把写好的shell加入到crontab中，可以定时运行shell
把写好的shell加入到crontab中，可以定时运行shell
#7
采用守护进程。
你所描述的就是守护进程所要做的，可以说是量身定制。
你所描述的就是守护进程所要做的，可以说是量身定制。
#8
1. 写一脚本检查被监测进程是否存在(ps)
2. 隔几分钟就运行该脚本(crontab)
2. 隔几分钟就运行该脚本(crontab)
#9
fork＋wait在某些情况下不失为是个办法，不过也满难管理的。呵呵，至少是个非常规办法。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
#10
mark
#11
回复人： loserking(刻舟求剑) ( ) 信誉：100 2005-12-07 20:16:00 得分: 0
fork＋wait在某些情况下不失为是个办法，不过也满难管理的。呵呵，至少是个非常规办法。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
======================================
不知道fork + wait都算是非常规，还有什么能算是常规的？
fork＋wait在某些情况下不失为是个办法，不过也满难管理的。呵呵，至少是个非常规办法。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
======================================
不知道fork + wait都算是非常规，还有什么能算是常规的？
#12
呵呵，fork和wait没什么不常规的，这么做也没什么技术上的不行。不过，写一个daemon来干这个感觉有点怪怪的。
再说，这个监控进程监控的对象很多情况下也是deamon吧，否则搞个shell循环就ok了。普通deamon进入daemon状态基本都要fork 2次。监控进程得到的只是最初的壳进程pid，那个几乎是立刻退出的。呵呵，监控进程恐怕要没完没了的fork了。
感觉上还有其它管理上的问题，我也不细想了。总之，用句围棋行话：味道很坏。
再说，这个监控进程监控的对象很多情况下也是deamon吧，否则搞个shell循环就ok了。普通deamon进入daemon状态基本都要fork 2次。监控进程得到的只是最初的壳进程pid，那个几乎是立刻退出的。呵呵，监控进程恐怕要没完没了的fork了。
感觉上还有其它管理上的问题，我也不细想了。总之，用句围棋行话：味道很坏。
#13
你加上了被监控的进程必须是daemon这个条件，还要确保可以知道这个daemon使用的pidfile的位置，并且要有权限读取这个文件。限制也不少了吧？
#14
我感觉楼主的意图是想监控一个daemon进程，所以我也是针对监控daemon进程来讨论的。呵呵，可能是我先入为主了。
如果是个普通进程，使用shell或者其他脚步几行就搞定。那行脚步的实际实现方式就是fork＋wait。
很多常见的daemon都会有这个pid文件，特别是socket server daemon。它不仅可以准确定位最终转入后台进程的pid，而且对于socket server还避免了进程重复创建的问题。对于多HOME多启动进程，也很便于管理。
这只是个推荐方式，推荐给写daemon进程的人注意这种方式。如果没有pid文件也可以使用ps嘛。不过在进程管理上，没有pid文件来的文雅。
在各个具体案例中，还是根据实际情况决定方案吧。
如果是个普通进程，使用shell或者其他脚步几行就搞定。那行脚步的实际实现方式就是fork＋wait。
很多常见的daemon都会有这个pid文件，特别是socket server daemon。它不仅可以准确定位最终转入后台进程的pid，而且对于socket server还避免了进程重复创建的问题。对于多HOME多启动进程，也很便于管理。
这只是个推荐方式，推荐给写daemon进程的人注意这种方式。如果没有pid文件也可以使用ps嘛。不过在进程管理上，没有pid文件来的文雅。
在各个具体案例中，还是根据实际情况决定方案吧。
#1
把它写到/etc/inittab中
如：
ME0:2345:respawn:/usr/local/sbin/tcserver >/dev/null 2>/tmp/stderr.tcserver
如：
ME0:2345:respawn:/usr/local/sbin/tcserver >/dev/null 2>/tmp/stderr.tcserver
#2
fork，然后wait.
fork出来的进程去做事情，死了以后父进程的wait会返回，你检查一下子进程的死亡原因，然后决定是否重新fork
fork出来的进程去做事情，死了以后父进程的wait会返回，你检查一下子进程的死亡原因，然后决定是否重新fork
#3
其实我是想在c程序里实现这个功能，因为我在重启进程时还要做一些日志记录的工作，所以光用写到inittab中的方法好像难以实现。
#4
我可能还要在程序里实现定时扫描某个文件的功能，不知道怎么实现?又要死循环？
#5
支持fork+wait这种方法。
#6
写shell去判断进程是否存在，不在就重新运行。
把写好的shell加入到crontab中，可以定时运行shell
把写好的shell加入到crontab中，可以定时运行shell
#7
采用守护进程。
你所描述的就是守护进程所要做的，可以说是量身定制。
你所描述的就是守护进程所要做的，可以说是量身定制。
#8
1. 写一脚本检查被监测进程是否存在(ps)
2. 隔几分钟就运行该脚本(crontab)
2. 隔几分钟就运行该脚本(crontab)
#9
fork＋wait在某些情况下不失为是个办法，不过也满难管理的。呵呵，至少是个非常规办法。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
#10
mark
#11
回复人： loserking(刻舟求剑) ( ) 信誉：100 2005-12-07 20:16:00 得分: 0
fork＋wait在某些情况下不失为是个办法，不过也满难管理的。呵呵，至少是个非常规办法。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
======================================
不知道fork + wait都算是非常规，还有什么能算是常规的？
fork＋wait在某些情况下不失为是个办法，不过也满难管理的。呵呵，至少是个非常规办法。
搞个cron是很常规传统的方法。不过用ps就太老套了。
每个daemon一般都有个pid文件。里面存放进程pid，而且在进程正常运行状态下，这个文件都是write lock的。这应该就足够了。
======================================
不知道fork + wait都算是非常规，还有什么能算是常规的？
#12
呵呵，fork和wait没什么不常规的，这么做也没什么技术上的不行。不过，写一个daemon来干这个感觉有点怪怪的。
再说，这个监控进程监控的对象很多情况下也是deamon吧，否则搞个shell循环就ok了。普通deamon进入daemon状态基本都要fork 2次。监控进程得到的只是最初的壳进程pid，那个几乎是立刻退出的。呵呵，监控进程恐怕要没完没了的fork了。
感觉上还有其它管理上的问题，我也不细想了。总之，用句围棋行话：味道很坏。
再说，这个监控进程监控的对象很多情况下也是deamon吧，否则搞个shell循环就ok了。普通deamon进入daemon状态基本都要fork 2次。监控进程得到的只是最初的壳进程pid，那个几乎是立刻退出的。呵呵，监控进程恐怕要没完没了的fork了。
感觉上还有其它管理上的问题，我也不细想了。总之，用句围棋行话：味道很坏。
#13
你加上了被监控的进程必须是daemon这个条件，还要确保可以知道这个daemon使用的pidfile的位置，并且要有权限读取这个文件。限制也不少了吧？
#14
我感觉楼主的意图是想监控一个daemon进程，所以我也是针对监控daemon进程来讨论的。呵呵，可能是我先入为主了。
如果是个普通进程，使用shell或者其他脚步几行就搞定。那行脚步的实际实现方式就是fork＋wait。
很多常见的daemon都会有这个pid文件，特别是socket server daemon。它不仅可以准确定位最终转入后台进程的pid，而且对于socket server还避免了进程重复创建的问题。对于多HOME多启动进程，也很便于管理。
这只是个推荐方式，推荐给写daemon进程的人注意这种方式。如果没有pid文件也可以使用ps嘛。不过在进程管理上，没有pid文件来的文雅。
在各个具体案例中，还是根据实际情况决定方案吧。
如果是个普通进程，使用shell或者其他脚步几行就搞定。那行脚步的实际实现方式就是fork＋wait。
很多常见的daemon都会有这个pid文件，特别是socket server daemon。它不仅可以准确定位最终转入后台进程的pid，而且对于socket server还避免了进程重复创建的问题。对于多HOME多启动进程，也很便于管理。
这只是个推荐方式，推荐给写daemon进程的人注意这种方式。如果没有pid文件也可以使用ps嘛。不过在进程管理上，没有pid文件来的文雅。
在各个具体案例中，还是根据实际情况决定方案吧。