On 7/19/05, Greg Hudson <ghudson@mit.edu> wrote:
> In
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=102837,
> Michael Sinz raised a good point which received no replies:
>
> > I may be a bit "old school" here but why is there so much work and
> > effort going into re-inventing "syslog" logging.
> [...]
> > Windows does have application event logging support [...]
>
> Server applications which run on Unix are historically somewhat split
> on whether they implement home-grown logging subsystems or use syslog.
> sshd syslogs, for instance, while httpd uses a home-grown subsystem.
> I tend to think that the former are being more responsible citizens,
> at least as Unix programs go. They tie into the system's central
> logging configuration and central log-rolling mechanisms.
>
> It's true that going with the native logging system on each platform
> would be a more difficult path. We'd have to add functionality to APR
> (which has never concerned itself with this problem because httpd uses
> a home-grown logging subsystem), and we'd have to figure out what the
> best native logging facility is on various platforms, as well as
> figuring out how to provide a uniform interface to those platforms'
> logging levels and facilities. But in the long term, a home-grown
> logging subsystem is extra complexity which we could never practically
> rid ourselves of.
>
> We could, of course, add configurable hooks to our home-grown logging
> subsystem (now or later) to log via the platform's native logging
> system. But we'd still have a bunch of gunk in the Subversion source
> base which reinvents the wheel.
>
> I'm not adamant about using the platform-native logging facilities,
> but before we get too far down the home-grown subsystem path, I'd like
> to hear arguments for that path over the platform-native one.
>
> One possible criticism is that using syslog on Unix unconditionally
> would not make it easy to interoperate with Dan Bernstein's
> daemontools as John Szakmeister (I think; both mail archives are down
> right now) desired. It's my opinion that it is not important or even
> desirable to put any weight on interoperating with djb's tools, since
> they are themselves designed without any weight for consistency with
> other Unix facilities.
>
I don't think we are reinventing syslog. Rather, we are simply
sending out our message to syslog. We want to find a flexible way to
write out our log messages to syslog and any other viable logging
system. Files/streams, syslog, daemontools are all just collectors
for our message, and in the ideal world, we'd want to support them
all. So, can't we make everyone happy?
I think as long as everything goes through a standard black box
interface then, in the end, we can always control where the message is
sent.
Whether we write to a stream, syslog, or the windows event logger, it
is at the core, just one line (or more?) of text. In the case of
syslog and the windows event logger, we can also provide loglevels.
To shed some light on the Windows method, here is an example function
that writes an entry in:
// Logs an "Error"-type event to the "Application" log.
void LogWin32EventError(LPCTSTR szMsg)
{
HANDLE h;
// Get a handle to the event log.
h = RegisterEventSource(NULL, "Application");
if (h == NULL)
{
return;
}
// Report the event.
ReportEvent(h, // event log handle
EVENTLOG_ERROR_TYPE, // event type (error)
0, // event category
0, // event identifier
NULL, // no user security identifier
1, // number of substitution strings
0, // no data
&szMsg, // pointer to strings
NULL)) // no data
// Close the handle.
DeregisterEventSource(h);
return;
}
Windows also has 5 levels of event types:
Error
Warning
Information
Success Audit
Failure Audit
For now, we can simply start with a system thats writes out to
streams, but also provides interfaces that will eventually allow us to
support any platform-specific method with enough demand. Everyone is
happy.
Ideally, I would like to see the complexity of a logging interface
like this hidden somewhere in apr-util.
- Brian Holmes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 21 02:55:09 2005