Stephen Hahn writes:
> * James Carlson <james.d.carlson at sun.com> [2008-04-30 20:08]:
> > A subsequent request or problem that causes the daemon to fault causes
> > the original invoker -- who may well have gone on to bigger and better
> > things -- to take the hit. Any others who came along are unaffected,
> > as it's an on-demand service which runs as long as there's work.
>
> Just so I understand: the inetd restarter's implementation of
> the service model is or isn't on-demand in this sense?
It is. It just has two issues that I can see:
- It's driven only by sockets and RPC, so doors and other IPCs need
not apply.
- The idle/active state is not directly visible except by doing
'pgrep' for the daemon related to the service (if you happen to
know the name). (That's just an observability nit; I don't care
nearly as much about that.)
I'm not sure whether it's a good idea to extend inetd to other IPCs,
but if we could then, yes, that'd solve at least this class of
on-demand items.
The other, related class of items that happen to behave this way are
cron jobs. See CR 6399739.
--
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
