Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

syslog local facilities



>You configure syslog to respond to a combination of facility.loglevel,
>where 'facility' basically refers to the type of application, and
>loglevel corresponds to severity.  local0-local7, along with more
>specific facilities like mail, kern, auth, lpr - refer to the type of
>application.  There are nine predefined facilities, plus these eight
>locally defined facilities.  I.E. - your application might not
>correspond to one of the nine predefined types, so you could elect to
>use the local facilities.  (I could be wrong about this, but that's been
>my understanding).

I am comfortable with syslog configuration, I just don't understand local
log utilization.  I have noticed that on RH 5.1 there was no boot.log
pre-configured on the distribution itself.  On RH 6.2, I noticed that RH
utilizes (and pre-configured) local7 for boot messages.  Is there a way to
find out which local log is being utilized by which (if any) application?
I want to write an application and like to utilize one of the local log
level for my application, but i don't want my application log messages to
be logged with messages of other applications.


>Your syslog daemon can accept remotely generated syslog messages if you
>start it with the -r option. 

This means even though syslog port 514/udp is enabled, no remote machines
can send messages to this particular port if syslog daemon runs without the
-r option?  

>From what I have read, syslog can be utilized via two interfaces: network
through port 514/udp and API.  If I close port 514/upd, would my system
still log ALL local (the same machine) messages as it would when I have
port 514/udp open?

Huy Le
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org