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.
> -- 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.
>> 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:
>> 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.
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list