Has there been any progress on this front? I was running resin under launchd before, but it's been broken for some time (not sure if it's because of something I did to my little launcher tool, or because I upgraded to 4.x).
On Feb 17, 2010, at 16:47:13, Rob Lockstone wrote: > > On Feb 17, 2010, at 2:10 PM, Scott Ferguson wrote: > >> Rob Lockstone wrote: >>> The preferred way to launch processes at boot/login in OS X since 10.4 >>> is to use launchd. >>> From <http://developer.apple.com/MacOsX/launchd.html>, "/The launchd >>> daemon takes over many tasks from cron, xinetd, mach_init, and init, >>> which are UNIX programs that traditionally have handled system >>> initialization, called system scripts, run startup items, and >>> generally prepared the system for the user./" >>> >>> All well and good. It's a nice service and reasonably easy to manage, >>> especially when using something like >>> Lingon <http://www.macupdate.com/info.php/id/19879/lingon>. However, >>> launchd has one feature that is annoyingly incompatible with Resin >>> 4.x; it kills all child processes that the first process started when >>> the first process exits. >> >> Thanks. I've added this as a bug report. It might be possible to add a >> "watchdog" argument like "console" for Mac (I'm not sure if the JNI will >> get properly loaded in that case, but I'm sure there's a way to work >> around it.) > > You're welcome. But I don't think it's a bug. Resin isn't the only "daemon" > or "thing that you want to act like a daemon" that isn't compatible with > launchd's default behavior of killing child processes. Which I guess is why > launchd provides the AbandonProcessGroup argument in the first place. > > Anyway, it works and I don't think it's doing any harm. It just wasn't > obvious (to me) how to get it working. > > I did try running it with the 'console' argument, but that (obviously) dumps > all the output to the console (stdout, stderr, even gc messages). I didn't go > as far as checking if ResinBoot still exits when starting with the console > argument, but as I recall the code, I think it does (could be wrong though). > > You'd have to add a "noexit" or "launchd-compatible" parameter, or whatever, > that stops ResinBoot from exiting. But presumably that would just eat up a > small chunk of memory for no reason other than to allow compatibility with > OSX's launchd. Unless it's a security risk, I think using AbandonProcessGroup > is preferable. I guess the other option would be to abandon ResinBoot and > fold its behavior directly into the WatchDog. > > Rob > >> >> -- Scott >>> >>> Unfortunately, from what I can tell, this is exactly what Resin 4.x >>> does. The ResinBoot class is responsible for creating the WatchDog >>> process, and the WatchDog is what creates and then monitors the main >>> Resin process, but after the WatchDog starts, ResinBoot exits so >>> launchd kills the child processes. >>> >>> So what's a girl to do? I don't know. I'm not a girl. But here's what >>> I did. >>> >>> Buried down in an Apple Developer Connection document, /Daemons and >>> Agents/, is a section titled "Careful With That Fork, Eugene" >>> <http://j.mp/bHw3XZ>. That's the section that explains how launchd >>> will kill child processes if the original process exits. But it also >>> lists a few work-arounds. The first two are specific to daemon and >>> probably not doable for Resin, at least not without mucking around >>> with Resin and rebuilding it. But the third, and of course >>> the "least-preferable" by Apple's standards, is to use the >>> AbandonProcessGroup property in Resin's startup plist file. >>> >>> Success! >>> >>> Once you have your .plist file created (easy with Lingon), you can >>> either edit it directly (it should be in /Library/LaunchDaemons), or >>> within Lingon switch into "Expert Mode" and choose the >>> /AbandonProcessGroup/ parameter from the "Insert parameter..." drop >>> down. It will look like this in the plist file: >>> >>> <key>AbandonProcessGroup</key> >>> <true/> >>> >>> Here's the definition of AbandonProcessGroup: >>> >>> AbandonProcessGroup <boolean> >>> When a job dies, launchd kills any remaining processes with the >>> same process group ID as the job. Setting this key to true disables >>> that behavior. >>> >>> I can't say this is the best/only solution, but it worked for me. >>> >>> Rob >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> resin-interest mailing list >>> email@example.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >> >> >> >> _______________________________________________ >> resin-interest mailing list >> firstname.lastname@example.org >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > _______________________________________________ > resin-interest mailing list > email@example.com > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list firstname.lastname@example.org http://maillist.caucho.com/mailman/listinfo/resin-interest