debugging messages from a daemon program

[Will Parsons]

I'm developing a daemon written in Ruby and in the course of development I
like to see various status messages printed at crucial points to aid in
debugging. Since this is a daemon, I use syslog and create a global $log
variable to handle log messages, essentially like the following:

require 'syslog'
....
$log = Syslog.open('progname', Syslog::LOG_PID, log_facility)
....
$log.debug some_message

This has worked well as long as the whole program is contained in a single
file, but as the program has gradually increased in complexity, I wish to
remove the definition of some classes to their own files and "require" them
in the main ruby source file. This means that whatever is removed to a
separate file no longer has access to the global variable $log. Any
suggestions on how to best handle status/debug messages from these
subsidiary files?

 

[Ken Burgett]

[Note: parts of this message were removed to make it a legal post.]

I just did some development on a daemon, and I understand your pain.

I had some luck using the ENV hash: ENV['logger'] = Logger.now(...)

I'm developing a daemon written in Ruby and in the course of development I
like to see various status messages printed at crucial points to aid in
debugging. Since this is a daemon, I use syslog and create a global $log
variable to handle log messages, essentially like the following:

require 'syslog'
...
$log = Syslog.open('progname', Syslog::LOG_PID, log_facility)
...
$log.debug some_message

This has worked well as long as the whole program is contained in a single
file, but as the program has gradually increased in complexity, I wish to
remove the definition of some classes to their own files and "require" them
in the main ruby source file. This means that whatever is removed to a
separate file no longer has access to the global variable $log. Any
suggestions on how to best handle status/debug messages from these
subsidiary files?

--
Regards,

Ken

Seek wisdom through disbelief

 

[Brian Candler]

I wish
to
remove the definition of some classes to their own files and "require"
them
in the main ruby source file. This means that whatever is removed to a
separate file no longer has access to the global variable $log.

Why? A global variable is global - it should be visible from any file.
As long as your main program initialises $log before any of the
subsidiary files try to use it, you should be fine.

Are you saying you want to run these subsidiary files by themselves,
independent from the main program which initialises $log?

One way to do that is to initialise $log in a separate library.

Note that the Syslog API is Syslog.debug, Syslog.warning etc. So you
don't actually need to set up a global variable, but if you do, it
should be set to Syslog (which is also the value returned by
Syslog.open)

---- mylog.rb ----
require "syslog"
Syslog.open('progname', Syslog::LOG_PID, Syslog::LOG_DAEMON)
$log = Syslog

---- main.rb -----
require "mylog"
require "subsid"
$log.warning "Starting"

---- subsid.rb ----
require "mylog"
$log.warning "Loading library"

An advantage of setting $log is that you can point it to a different
object with a duck-type interface. Logger has a similar interface,
although annoyingly it's Logger#warn vs Syslog.warning

A more sophisticated approach to setting up shared objects like loggers
is to use dependency injection. See if you can find a copy of Jim
Weirich's depinj.rb, which unfortunately is no longer available at
http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc

 

[Brian Candler]

I had some luck using the ENV hash: ENV['logger'] = Logger.now(...)

The ENV hash is the OS environment. It's only supposed to contain
strings.

You can make another global hash of objects if you like:

SERVICES = {}
SERVICES['logger'] = Logger.new(...)

But that's not much different to using global variables.