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