David Powell writes:
> James Carlson wrote:
> > Only fatal signals from outside of the process contract (if I
> > understand the documentation correctly) are treated as a special
> > event. Ones inside the same contract are not.
> >
> > That's why doing "pkill sendmail" doesn't work anymore.
>
> Actually, since sendmail also has an event hooks mechanism (.forward
> files), the sendmail service asks SMF to ignore core files and
> externally generated signals.
Interesting. I wonder if that's really the right answer there.
Wouldn't it be more correct to have sendmail create a new process
contract when it wants to run an executable $HOME/.forward or "|"
target in /etc/aliases?
Otherwise, this means that (say) the smmsp copy of sendmail can drop
core, but the system will fail to restart the service, and the user
will be left with a partly- and silently-failed mail system.
> pkilling sendmail causes a restart because (usually) all processes in
> the sendmail service are called sendmail.
... which sounds like it wouldn't catch the failure above. :-<
The general issue is that code that once did fork/exec with some
abandon now needs to be examined carefully to discover the original
author's intent: if the intent was to share fate with the exec'd
process, then no problem. If the intent was to have classic UNIX
semantics ("you go your way, I'll go mine"), then it's a problem.
I'd still, though, like to see an SMF "idle" state for on-demand
services. I'll file an RFE on that. Having it would solve the
problem of dhcpagent, in.mpathd, and several other daemons quite
nicely.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
