On Mon, Aug 28, 2006 at 05:43:26PM -0700, David Powell wrote:
> On Mon, Aug 28, 2006 at 04:35:11PM -0500, Nicolas Williams wrote:
> > So, as a follow-up to the "SMF deadlock?" and "SMF and child processes"
> > threads I wrote an LD_PRELOAD shared object that allows one to "target"
> > certain calls to fork() and put the resulting child processes into new
> > process contracts.
> >
> > Selecting which calls to fork() should create new process contracts
> > turns out to be a non-trivial task and I don't yet see how to integrate
> > this LD_PRELOAD hack into OpenSolaris itself.
>
> I recommend against trying. When a program calls fork() is an
> implementation detail of the highest order, and fixes using such a
> library will be correspondingly fragile. The only way to determine
> if an application of this fix is correct is to examine the source, at
> which point you might as well modify it.
Yup. I have no intention to pursue this as anything other than a
porting tool for third parties ("does this hack make the problem go
away? ah, then I know how to change the application") or a way for some
customers to get relief (think of abandoned third party software -- that
happens).
> > BUT, this could be a useful tool for anyone trying to create SMF
> > profiles for third party software that they can't modify, and/or a
> > porting tool for vendors/maintainers of such software.
>
> The former is recipe for upset when the predicted behavior and actual
> behavior diverge. The latter is terrifying.
The former can provide relief, but is unstable. By the latter I meant
that a developer could easily check whether changing his application to
put child sessions in new process contracts would help, not that they'd
ship this shared object!
> > As for RFEs for OpenSolaris, maybe we should consider an extension to
> > posix_spawn(3C) to specify that the spawned process should be in a new
> > process contract?
>
> That's an interesting possibility.
I think posix_spawn(3C) is the probably right place to deal with lots of
things, like zone_enter(2), perhaps.
> Strictly speaking, we already have that. It's the behavior you imply
> that we don't: you don't want the second fork or a fork in the child
> to create a contract. For that we have the following bugs:
>
> 5080413 one-shot active template option desired
> 5080414 option to clear active process contract template on child side of
> fork() wanted
>
> (These probably look familiar ;^)
I remember :)
> If you are a simple application, you might not care about the
> contracts once they are created, in which case a fix for
>
> 5076884 a mechanism for automatically abandoning process contracts on
> creation
>
> would also be useful.
Most apps that create process contracts to hold child sessions want them
to avoid having sessions killed when the service gets restarted (e.g.,
sshd(1M), inetd(1M), cron(1M)).
> Though using any of these requires application changes, those changes
> will hopefully be very simple. I think it is a much saner approach
> than trying to coax naive applications into being consumers of a
> fault model they weren't written to be aware of.
Except that usually they don't care to get any events and wouldn't be.
The only aspect of the new fault model that they care about is this:
don't kill my sessions when I die/you kill me.
Nico
--
