[PATCH] LogTailer ignores config.log_path

Unfortunately I couldn't manually test the full-stack since the rake gem task fails on my machine, but the attached patch should do the trick.

This will make it easier to distribute Rails apps as gems.

Tossed this around and I can't find a problem with it. The github repo is flipping out on a credits.erb file when generating the guides, but I disabled that and created a sample rails app, etc. Looks good to me.

+1, btw

Also breaks when using SyslogLogger and no log file is found in RAILSROOT/log. (Of course, rails creates the empty logfiles when the app is generated, but I didn't want them in my repository...)

Felipe: can you elaborate? Does rails break with SyslogLogger in its current state, or after this patch is applied?

Phil: Sorry for the long silence. As it turns out, my issue persists with or without patch. However, I don't know if the error lies in rails or SyslogLogger:

• rails 2.1.0 application, configured with SyslogLogger as RAILS_DEFAULT_LOGGER, starts up fine even if .log does not exist.

• rails 2.3.2 application, configured with SyslogLogger as RAILS_DEFAULT_LOGGER does not start up if .log is mssing, fails with:

rails-2.3.2/lib/rails/rack/log_tailer.rb:10:in size': No such file or directory - <path_to_approot>/log/production.log (Errno::ENOENT)

Oddly enough, if I remove the SyslogLogger configuration from the production.rb environment config, the missing logfile is created during the boot up. With SyslogLogger, the file is not created and log_tailer complains about its absence. Not critical though, since just touching the missing file will work fine. Just not pretty ;-)

Maybe I should file this somewhere else?

I think this issue is bogus.
It looks to me that rspec-rails, when required, automatically sets the RAILS_ENV to 'test' which also changes the logfile name in the LogTailer.

Fix:

do NOT load your test-framework gems in 'development' and 'production' environments.

whoops. desregard my last posting. i was certifiably insane then...

I found this because I'm having the same problem. FYI, the patch doesn't fix the problem when using any logger other than the default logger and either 1) you use a non-standard file name and you don't set config.log_file or 2) there is no file (remote logging). Normally when using an external logger you often don't set config.log_path so the patch doesn't get the new filename or if you are using a remote logger there is no filename for LogTailer to open.

This goes away if you run the server detached as LogTailer is bypassed then. However, I prefer to run it normally (not detached) and redirect stdout/stderr to a log file (you sometimes get useful debugging info from it).

It would be nice if there was another way to turn off the LogTailer but I haven't found one I like yet (I generally don't like patching due to work required to maintain the patch when you upgrade versions). Maybe it would be better if LogTailer looked for the file and if the file wasn't found then LogTailer does nothing (let the server continue without it)? Maybe output a message to let the user know. Or maybe disable if there is an external logger defined (and config.log_path isn't set?).

You could set a custom formatter on the log object. This may not work for SyslogLogger because I don't think it conforms with the built in Logger interface.

Here is an example:

require 'logger'

class FormatterProxy < Struct.new(:formatter)
  def call *args
    msg = formatter.call(*args)
    puts "HI!!! #{msg}"
    msg
  end
end

logger = Logger.new $stdout
logger.add(Logger::DEBUG, "before override\n")
logger.formatter = FormatterProxy.new(
  logger.formatter || Logger::Formatter.new
)
logger.add(Logger::DEBUG, "after override\n")

Umm, bump. This is a really obvious and fatal bug. I'm monkey-patching to get by for now.