Lubomir Petrik - Sun Microsystems wrote:
> I'm creating a manifest for service application/A that starts some
> master daemon and this daemon later starts some other processes which
> start yet another processes. My current problem is that when master
> daemon is killed it's not restarted due to other running processes in
> the contract. So I'd like to decouple the master daemon and the other
> processes. These other processes are the same except for the arguments
> they have, so I could introduce a service application/B that would
> depends on application/A and would contain all the other processes. But
> I don't see a way how to do that, since normally the processes are
> started by the master daemon. I would like the most if I could have just
> one instance of application/B and somehow say start this process as part
> of service B. Is there a way (libscf does not help me much)?
>
> Other solution for me would be if I could say only the processes when
> SMF start method exited should be part of the contract. If such process
> spawns another process, SMF would ignore it, as I don't really care
> about it. But I suppose there's no such thing right?
>
> Is this solvable without rewriting master daemon logic much?
As Mike pointed out, you can definitely accomplish this by putting
those other processes in another contract. Before I'd recommend
that, though, I'd like to understand what the relationship between
these processes are.
What is killing the master process? How is it being killed?
It is this happening in an error situation?
What is the relationship between the master process and the child
processes?
Would it be acceptable for the child processes to be restarted when
the master process is restarted?
If not, does the replacement process have a relationship with those
processes?
If not, how is the administrator expected to operate on the
subordinate processes, if they are left running when the master
process is restarted?
Dave
