John Levon wrote: > I have the following scenario: > > A daemon (xend) under SMF control spawns a number of processes. I need > to run these under a separate contract, so they aren't killed when xend > restarts. > > To avoid having to write a bunch of C and Python I'd like to use ctrun. > However, it doesn't quite seem to do what I need. > > In particular, xend expects to get a PID it can later use to kill off > the child process. The only way to get this from ctrun, however, is by > parsing the human-readable output, which is obviously a bad idea (and > besides, is commingled with the sub-process's output). > > I could workaround this by using: > > ctrun -l contract -o noorphan ... > > Then xend would kill ctrun, which in turn would kill the contract's > members. But of course this leaves a completely unnecesary ctrun process > running. > > Suggestions? There doesn't seem to be a great way of getting the process > (or contract ID) back out. Hopefully I'm missing something obvious.
ctrun doesn't have an interface for getting the PID because one of the ideas behind contracts is that the first process isn't necessarily the interesting one. If the first PID happens to be the interesting one, you can always get it by ctrunning a wrapper that emits the PID of the process it starts in a format best suited to your application. ctrun doesn't have an interface for getting the CTID because at the time I had a hard time coming up with a use case that itself wasn't a partial solution. That doesn't mean we shouldn't have a way to get the CTID. I'm not sure ctrun -l contract -o noorphan solves your problem. If ctrun is started by xend, you will then have the problem that the ctrun processes will be in the same contract as xend, and will propagate the restart you were trying to insulate your subprocesses from. You could instead put the ctrun in another contract, but then you're back trying to find the PID of a process started by your outer ctrun. Dave
