python程序 如何 结束自身 延时1分钟 然后重启自身

[fdsfsdfsdf3334]

我的程序是个采集程序

有时候 可能数据库出现问题 比如连接不上

我使用了 try 语句

在出错的时候，我想让他 延时1分钟， [也就是等待一分钟，]

然后重启自身 [重新启动 重新连接]

[tan9le]

不可以是两个python程序么？A程序就是你的正常应用，发生异常以后将错误码作为参数唤起B应用，B应用记录LOG信息,sleep/wait一分钟以后唤起A应用，同时B应用结束。

[loading]

@tan9le 求demo

[a591826944]

time 不是有个sleep么 你可一 try 失败的时候 sleep啊 然后 递归 不久好了么

[tan9le]

@loading 木有demo，我是做J2EE的，Python应该也有类似于Java中的Runtime.exec的机制吧，就是调用系统命令。

刚刚查了一下，import os之后，os module里的popen、system方法貌似都可以调用系统命令，可以os.system('命令');来执行呀，python Path of B程序就是了。

[clino]

用 supervisor 来管理这样的进程吧, 配置一下相关参数就可以了

[loryyang]

你为什么一定要退出？你确定有必要这么做吗？

[strak47]

time.sleep(60)就行了吧

[nybux]

后台启动一个shell执行，sleep 60 && <你的脚本>
类似于这样:
echo "sleep 60 && echo 'a'" | sh

[ritksm]

为什么没有人提http://docs.python.org/2/library/subprocess.html

a.py用subprocess调用b.py.然后监控退出.异常退出重启即可
a.py可以有自己的退出逻辑，不如b.py失败10次，一个while的事情

[fdsfsdfsdf3334]

@loryyang 退出的目的是为了重启， 连接失败后，我该怎么引导程序再次执行链接数据库呢 如果一直连接不上呢 不太方便哦 又要写很多代码 主要是太麻烦了 重启比较简单

[Maslino]

@fdsfsdfsdf3334 ORM或者数据库driver一般可以配置自动重连。如果抛异常，考虑截住异常然后sleep一段时间（比如指数退避）然后重试。

[loryyang]

@fdsfsdfsdf3334 总感觉从程序逻辑讲，处理连接异常也是你的python程序需要处理的一种情况，把这种情况交给python外部的程序处理有点责任混乱了。
但是如果是你自己玩玩那倒无所谓，你用一个守护进程就ok了，守护进程通过pid监控python程序，如果发现python程序消失了，sleep60秒，重启python程序就ok

[fdsfsdfsdf3334]

@loryyang 是个企业级应用 同步公司的一些数据 目前 可以长期运行在服务器上， 不会出现意外，唯一的意外是 如果远程数据库重启了， 那么这里的成就会报错 奔溃， 目前我还没写 数据库连接的容错代码，想选个安全 高效 齐全的方法

[9hills]

又是一个X-Y问题，不去解决数据库重连，反倒是想重启整个Python脚本。。

[loryyang]

@fdsfsdfsdf3334 那就在python代码里面改吧，数据库连接重试是个常见问题，肯定有很多的解决方案了的，不会花费太多精力的

[loading]

@9hills 是我不好，我没提出来，而且歪楼了…

[suriv520]

我的经验是：当你发现自己的某个设计做起来很难的时候，一定是打开方式有问题……这种情况放开思路多想想，比往牛角尖里钻要划算……

普通青年
用Supervisord这个神器护身，或者subprocess开工，或者调外部命令（Linux下的at命令你知道的吧）重启。也懒得管程序里崩出了什么错误，反正最外面有专业防泄漏直接重启进程。

2B青年
有时候不知道到底是数据层出问题了，还是应用出问题了，还是系统哪个地方死翘翘了。怎么搞？不怕！把所有的必需服务都设成开机自启动，cronjob里加检测脚本，一旦出问题，祭出reboot大杀器……

文艺青年
在DB层的connection handler里加入异常重连。重连几次仍然失败的情况下直接抛出异常，让主循环的循环体直接崩掉，sleep一段比较长的时间后再开始主循环。

砖家叫兽
这种问题简直不叫问题了……你一定还没听过DBUtil、SQLAlchemy之类的杀器吧……

[fdsfsdfsdf3334]

@suriv520 确实没听过 我去研究看看

[Muninn]

我写类似的东西,都是先连接然后捕获
要是没连接上 隔30秒重试
再不行隔1分钟
然后2分钟 4分钟
设置个最多的次数
三四行就搞定了...

[vbs]

supervisor +1

[mongodb]

@suriv520 2B运维青年前来报道 =。=
这种2B的土办法虽然不入流，但是——
在没人手赶时间的生产环境里，往往是极好用且最能快速解决问题的方法。

解决掉问题了，再切换到普通青年模式——或者开发部的文艺青年比如 @aveline 终于上班了，就让他来文艺的处理掉……

尤其是在分秒必争的环境里，2B青年的解决方法其实往往是最快能恢复业务的唯一办法。。。

[stevenyou]

用 cron
http://en.wikipedia.org/wiki/Cron

[arcas]

一个master 多个 worker?

[suriv520]

@mongodb 角度不一样，结论不一样。
从运维的角度来讲，你的观点完全正确，并且也是主流的。
从商业角度讲，你的观点也完全正确。
但如果你们公司的开发把这样的产品交付给你们，还认为重启是理所当然的，那你大可让他们按照上述分类对号入座。

[lixm]

@suriv520 重启是理所当然的，一旦出现问题，尽快退出，交由supervisor善后重启，这样的思路很对啊，erlang就是这么干的

[suriv520]

@lixm 『重启』本质上是最粗暴的『异常处理』,怎能说『理所当然』？如果Nginx三天两头崩一次，如果MySQL三天两头崩一次，你敢用？

[suriv520]

@lixm 另外，Erlang怎么干，是取决于人，而不是程序语言本身。即使退一步来讲，按照正常的erlang并发理念，它崩，也是崩的单条轻量协程。并且即使是崩了，也还会进行一系列的善后，类似事务回滚。这整个过程的Behavior是设计好了的。用一句比较装的话说即『发生异常也是程序功能之一』。
这个问题说白了，就是异常处理的粒度问题。
但所谓『快速简单粗暴』的重启理念，在coding的时候过于依赖，真不利于水平的进步。如论如何，我是不敢苟同的。

[suriv520]

@lixm 当然，如果你和 @mongodb 一样，是做运维这一块的。那你有这样的思路才是正确的：因为你不是开发，没办法让它不崩……但崩了不重启，领导就找麻烦了……