site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com On Oct 3, 2008, at 2:04 PM, Jason Coco wrote: I was creating it with the SocketNamePath key in a dictionary I called IPC in the Sockets dictionary... I realized my problem though, I was using an intermediate directory that didn't exist and I guess launchctl didn't want to create for me :) I changed it to use a full path that already exists and it works just fine now. Thanks!! Did you get a chance to read my other question about the design? I was wondering if you had any opinion one way or the other... two launchd entries with the java one dependent on the wrapper or having the wrapper fork/exec the java process and then manage it actively. launchd does not allow you to express dependencies except through IPC. Using two plists is not the approach you want to take. The wrapper doesn't have to actually fork(2). All you need to do is get the process far along enough to get the file descriptor, then it's done. So just use the launch(3) APIs to grab the file descriptor, stash it somewhere in your process (like in an environment variable) and exec (2). Then have your Java app check that environment variable for the descriptor index and do its thing. Or you could pass the descriptor as a command line argument. -- Damien Sorresso BSD Engineering Apple Inc. smime.p7s