Re: [Fwd: [fuse-devel] Signal handlers]

[Valient G. <vg...@po...>]

Petric Frank wrote:
>Hello Miklos,
>
>On Saturday 08 January 2005 12:36, Miklos Szeredi wrote:
>  
>>Well, stderr of daemons is not too useful (e.g. if the xterm goes
>>away, stderr will be lost anyway).  So either you should run it in the
>>foreground, or use syslog.  That reminds me, that I should convert
>>libfuse to use syslog instead of stderr...
>>
>>Actually syslog(...) is easier to use than fprintf(stderr, ...),
>>because of an additional format string: %m, which adds
>>strerror(errno).
>>    
>
>I wrote a C++ syslog classes which creates an output stream to syslog for my 
>  
I also ended up writing logging code for my fuse-based filesystem.  I 
eventually split the logging into a separate project -- 
http://freshmeat.net/projects/rlog/

It uses printf style logging messages, and includes methods to capture 
to stdout/stderr, and syslog.  It has been tested to build and run on 
various Unix based systems, and also Windows.  Here is the summary from 
freshmeat:

*About:*
RLog provides a flexible message logging facility for C++ programs and 
libraries. It is subscription based, meaning you can subscribe to 
messages of your choice in an number of ways: by hierarchical channel 
name (e.g. "debug", "debug/special", "error", etc.), or filename, 
component name, etc. Log messages are individually enabled. It is meant 
to be fast enough to leave in production code - even where it may be 
called many times, as both the GCC and Intel compilers reduce the 
logging overhead to a few clock cycles if they are dormant (with no 
subscribers). Other add-on components can extend subscriptions to 
external programs, allowing you to enable and collect debugging messages 
remotely.