我有一个守护进程，我写的是由SMF执行的。问题是当发生错误时，我的代码失败，然后需要从头开始重启。现在它正在发送sys.exit（0）（Python），但是SMF一直把它扔进维护模式。
我已经与SMF合作，知道它有时会自动重启某些服务（并让其他人失败并让你像这样处理它们）。如何将此流程归类为需要自动重启的流程？它是SMF设置，失败的方法，是什么？
答案 0 :(得分：1)
假设一个正常的服务清单，我怀疑你正在进入维护，因为SMF 重新启动你“太快”（这有点任意定义）。 svcs -xv应告诉您是否属于这种情况。如果是，SMF正在重新启动你，然后你又快速退出，并决定放弃直到问题得到解决（并且你手动svcadm clear了它。
我想知道退出0（并表示成功）可能会引起进一步的混淆，但似乎不会出现这种情况。
我认为Oracle Solaris不允许您调整SMF认为“太快”的内容。
答案 1 :(得分：1)
Solaris使用startd/critical_failure_count和startd/critical_failure_period的组合，如svc.startd manpage中所述：
startd / critical_failure_count
startd / critical_failure_period
critical_failure_count和critical_failure_period属性一起指定在 svc.startd 将服务转换为维护之前的给定时间间隔内允许的最大服务失败次数。如果在critical_failure_count秒的任何时段内失败次数超过critical_failure_period， svc.startd 会将服务转为维护。
默认值可在源中找到，值depends on whether the service is "wait style"：
if (instance_is_wait_style(inst))
critical_failure_period = RINST_WT_SVC_FAILURE_RATE_NS;
else
critical_failure_period = RINST_FAILURE_RATE_NS;
默认值为5 failures/10 minutes or 5 failures/second：
#define RINST_START_TIMES 5 /* failures to consider */
#define RINST_FAILURE_RATE_NS 600000000000LL /* 1 failure/10 minutes */
#define RINST_WT_SVC_FAILURE_RATE_NS NANOSEC /* 1 failure/second */
可以在SMF as properties中设置这些变量：
<service_bundle type="manifest" name="npm2es">
<service name="site/npm2es" type="service" version="1">
...
<property_group name="startd" type="framework">
<propval name='critical_failure_count' type='integer' value='10'/>
<propval name='critical_failure_period' type='integer' value='30'/>
<propval name="ignore_error" type="astring" value="core,signal" />
</property_group>
...
</service>
</service_bundle>
检查启动值后，如果服务为“等待样式”，则为throttled to a max restart of 1/sec，直到它不再以非cfg错误退出。如果服务不是“等待样式”，则为put into maintenance mode。
答案 2 :(得分：0)
您必须创建服务清单。这比没有复杂。这有示例清单并记录清单结构。
http://www.oracle.com/technetwork/server-storage/solaris/solaris-smf-manifest-wp-167902.pdf
答案 3 :(得分：0)
事实证明，我连续两次确认所有内容都已正确终止。第二个，当然是退出0以外的东西。更改此选项以在脚本末尾包含exit 0解决了问题。