Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
>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 | |
We also thank MIT for the use of their facilities. |