James Carlson wrote:
> 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?
Yes. But I'll let you convince John to make the Solaris-specific
changes to sendmail :)
> 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.
Unfortunately, yes.
>> 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.
...which is why when a contract is created you have the ability to
specify how strict you want its enforcement to be.
If you ignore signals and core files, a process running in a contract
should behave consistently with classic UNIX semantics. Because an
unmodified sendmail relied on those semantics, we did exactly that.
> 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.
This sounds a lot like inetd; inetd doesn't use another state.
I'm not saying an "idle" state would be a bad thing, but I'd argue
that inetd and idle service support should behave the same way.
Dave
