Hallo David,
thank you for the detailed and helpful answer. I'm afraid we will need some
days to dig deeper and to find out what was the most suitable approach and why
we can't see what you would expect in all cases.
> So if you run the above code before your daemon daemonizes, your
> daemon will be in one contract, and any process it forks and execs
> will be in its own individual contract. If you run the above after
> you daemonize, only your children will be in newly created contracts
> (though they will each be in their own). Assuming your children
> immediately exec, *their* children will be in the same contracts as
> their parents.
To make svc.startd see its running child process (our daemon) we do not do the
standard "daemonize" stuff (fork, exit ...) as if the daemon was started from
the command line (this behaviour is switched on by the -w (wait) flag). But all
the other stuff (session id, filedescriptors, wd ..) is done. It is almost the
same like with sshd started from inetd.
So your expectation is fulfilled, the daemon is in its own contract.
(which seems to have nothing to do with our code inserted for contract
handling). Processes that it forks appear in a separate contract which is
enough for the moment. That there is a separate contract for children is the
result of the code we inserted (see my last posting).
Taking into account your explanations I would expect that all children had an
individual contract. But what we see is that they all (even children of
children) share the same contract even though it is not the same like the
daemon.
To illustrate this we have started some more xclocks and one xclock started
from a shell script (which is no exec):
# ps -e -o pid,ppid,ctid,args
2900 2898 109 /test/app/xclock -bg yellow -t a1 xclock indirect -n gcdp
1354 1 109 /test/app/xclock -t a2
2742 1 109 /test/app/xclock -t a3
2423 1 109 /test/app/xclock -t a4
2579 1 109 /test/app/xclock -t a5
2898 1 109 /usr/bin/ksh /test/app/start_xclock
3055 1 109 /test/app/xclock -t a6
592 7 86 dvamd -w
7 1 4 /lib/svc/bin/svc.startd
We see the same contract for all children of the daemon and perhaps this is
useful to avoid running out of contract resources. We will need to do some more
testing with different code expamles to get more clarity.
> If you use popen() (or any other system call that creates another
> process) you'll need to do the same thing.
This seems a little bit difficult to me because I always thought there were no
calls to be made between popen and pclose (except read/write). The fine thing
about popen() is that one doesn't need to worry about exec, fd's, pipes and so
on.
Nevertheless, we still have to do some work to better understand the
programming models for contracts.
Thanks
bert
This message posted from opensolaris.org
