Bert, On Wed, Jul 12, 2006 at 12:22:56AM -0700, Bert Miemietz wrote: > > 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.
Sounds good. > 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. That certainly is odd. Note, however, that all your child processes have been reparented to init (pid 1). This indicates that an intermediate process, not dvamd, was directly responsible for their creation. I suspect that dvamd only forked once to create that process, and it was that process which started all the xclocks and ran the shell script. > > 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. I'm not aware of such a restriction. Dave
