Christine Tran wrote:
> I seem not to understand what contract deems to be "fatal" and
> "non-fatal" signal.
A "fatal" signal is a signal whose delivery causes the recipient to
exit immediately (due to the signal's disposition).
> ### Case 1: Start up sendmail, set hwerr and signal to be fatal event.
>
> Kill SIGTERM one sendmail process, one remains.
> ### Case 2: (same as case 1) Start up sendmail, set hwerr and signal to
> be fatal event.
>
> Kill SIGKILL one sendmail process. ctrun detect signal event, kills
> what's left in the old contract, starts a new one.
> There is a distinction which the contract framework makes, which does
> not matter to me. SIGKILL is fatal, but SIGTERM is not. I as a user
> don't really care, the end result is the same to me, pids in the
> contract eventually all exit. Why is this? Why this distinction, I
mean.
Normally SIGTERM would be a "fatal" signal. However, sendmail
installs a signal handler for SIGTERM:
$ psig $(pgrep -n sendmail) | grep TERM
TERM caught runners_sigterm RESTART,SIGINFO
When you send sendmail a SIGTERM, it handles that signal and later
decides to exit of its own accord. This is impossible to distinguish
from IPC, and is not considered an error.
> And why won't ctrun restart for me on the critical event "empty"?
ctrun only performs restarts on error conditions, not when the last
process exits gracefully. If that too can be an error condition, it
is up to the caller of ctrun to restart it. ctrun is provided to
encapsulate contract handling, not svc.startd-like policies.
Dave
