AltME groups: search

http://www.cyberciti.biz/tips/howto-linux-unix-write-to-syslog.html

During boot of Kubuntu 7.10 linux, I noticed a message that flashed 
by, something like
... corrupt .. not cleanly unmounted(?)... 

I checked all the logfiles listed by syslogd-listfiles -a and didn't 
find "corrupt" or "clean" in any of them.
These are the files I checked:
$ lsa `syslogd-listfiles  -a`
-rw-r----- 1 syslog adm  10197 2010-07-09 17:04 /var/log/auth.log

-rw-r----- 1 syslog adm 190194 2010-07-09 16:02 /var/log/daemon.log
-rw-r----- 1 syslog adm 119543 2010-07-09 15:56 /var/log/debug
-rw-r----- 1 syslog adm 210453 2010-07-09 15:56 /var/log/kern.log
-rw-r----- 1 syslog adm 191106 2010-07-09 17:02 /var/log/messages
-rw-r----- 1 syslog adm   8051 2010-07-09 17:02 /var/log/syslog
-rw-r----- 1 syslog adm   3580 2010-07-09 15:56 /var/log/user.log

I'd like to know the way to capture those boot messages.
Any ideas?

re System logging service: it's not an option because :
- not a cross-platform solution

- some files *have* to be generated directly by Cheyenne (like the 
HTTP log file)

- the trace output in debug mode can generate huge entries that are 
inappropriate for syslog

- the trace output needs to be free from non-Cheyenne entries (or 
it might become unpractical to use for developers)

Anyway, sending a few messages to syslog daemon to notify Cheyenne's 
starting/stopping or signals received might be a useful thing to 
be more sysadmin-friendly.

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

You can use debug/* logging functions, but they will only log in 
%trace.log file. Writing directly to a log file from RSP script is 
unsafe (unless you take great care about concurrent accesses). So, 
if you want to have custom logs from RSP scripts, you should use 
the OS syslog service for a really realiable solution. The debug/* 
log functions use their own solution for serializing disk writes, 
they are passing data to Cheyenne main process that does the writings 
to disk.

You could also make your own syslog server with 0MQ and send log 
messages to it from RSP scripts. That will offload the writing to 
a different process and 0MQ will take care of serialisation

Reliable and efficient file locking is hard to achieve, I agree with 
that. That's why I went for a syslog-like solution for Cheyenne.