Our RCP application logs a fair bit, but only INFO and above are output to console.
On windows/linux this is ok, but on OSX all logging seems to be passed to syslogd, which then decides what to log and not log, this means handling thousands and thousands of FINEST log messages, this makes syslogd use 140% cpu and gobble up memory. After running our app for about 3 minutes syslogd uses 2.5gb of memory and the whole system becomes unusable. Killing syslogd/rebooting is the only cure.
Starting the app from console makes it log directly to console, and there is no problem.
How can I stop syslogd handling my RCP logging on OSX?
Take a look at your RCP Application's RCP.App/Contents/Info.plist file. The default file generated by the RCP product build has <string>-consoleLog<string>.
This may be why everything ends up in syslogd.
I'm not at all familiar with Eclipse RCP, but I do have some experience with syslog. You are probably logging using either
local1 as the facility. OSX directs
local0.* to /var/log/appfirewall.log and
local1 to /var/log/ipfw.log. If you are logging to either facility, then everything you log is going to be written to disk.
I would start by first looking at if and how you can configure the syslog facility that your application is logging to. Once you figure out which facility it is logging to, you should be able to turn it off by editing /etc/syslog.conf and sending the syslog daemon a HUP signal. Read the manual entries for
syslog.conf for a detailed description.
You might also want to look into using a more Java-esque logging interface instead of syslog.
I have also been bit by this occasionally. My guess is this:
If you start Eclipse through Eclipse.app from the desktop, its console (stdout/stderr) will be redirected to the syslog, so any output by Eclipse itself (or plugins using printf) will end up there.
./eclipse in the Terminal.app and see if you get messages in the terminal window instead, and not to the syslog.
However, this of couse doesn't solve the problem that you actually don't want neither of them in the first place...Find out who's producing the output, and make them put it in the ErrorLog instead.
Unfortunately, I no longer know where this happened for me, so I can't test it. Good luck!