syslogd not behaving as expected

[Saurabh Kapoor_2]

Hi all,
I have an application which is integrated for logging to use syslogd.
In the /etc/syslog.conf file when I use the facility as USER then it logs it to the right file as specified in the /etc/syslog.conf but when I use the facility local0 then it does not. Is there any limitation on using the local0-7 facilities.

[Sundar_7]

Hi Saurabh,

I am not aware of such limitation. I do believe local0 is used by IPFilter to log the messages. But I dont think it exclusively locks the local0 facility.

I would suggest posting the contents of the /etc/syslog.conf file.

- Sundar

[Alzhy]

Do you have local0.* pointing to your the right file?

local0.* /var/logs/local0.log

for example?

[Saurabh Kapoor_2]

# @(#)B.11.11_LR
#
# syslogd configuration file.
#
# See syslogd(1M) for information about the format of this file.
#
mail.debug /var/adm/syslog/mail.log
*.info;mail.none;local0.none /var/adm/syslog/syslog.log
local0.debug /var/opt/SIU_01/log/sysloglocal.log
#*.info;mail.none;local0.none /var/adm/syslog/syslog.log
*.alert /dev/console
*.alert root
*.emerg *

[Geoff Wild]

Move local0.debug /var/opt/SIU_01/log/sysloglocal.log
ahead of syslog - then restart syslogd

Rgds...Geoff

[Saurabh Kapoor_2]

Hi Geoff,
I tried your suggestion, but still the same problem. I ran the syslogd in debug mode also and could see clearly that when I use the facility as USER then it says Logging to the coorect file and when I use local0 then it just ignores the filename specified in syslog.conf and starts logging to syslog.
any more suggestions...

[Geoff Wild]

What about moving the location of the log file? may be a permission thing...

Instead of:

local0.debug /var/opt/SIU_01/log/sysloglocal.log


Make it:

local0.debug /var/adm/syslog/sysloglocal.log

Rgds...Geoff

[Saurabh Kapoor_2]

Hi Geoff,
Tried it. Does not help.
I am getting to a point to think perhaps that the application I am configuring to divert its logs to a different location has some kind of a hard coding for the facility.

[Sundar_7]

Let us try this before giving up.

syslog is particularly sensitive about the spacing between the two fields.

# sed '/^local0.debug/d' syslog.conf > /etc/syslog.copy

# echo "local0.debug\t/var/opt/SIU_01/log/sysloglocal.log" >> /etc/syslog.copy

# mv /etc/syslog.copy /etc/syslog.conf

# kill -1 `cat /var/run/syslog.pid`

syslogd expects a after the facility. See if this helps and let us know.

[Alzhy]

Good catch Sundar..

I thought I posted the same findings about the TAB a few days ago..!

[Sundar_7]

I knew this for sometime now Nelson ! :-)

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=723241

[Saurabh Kapoor_2]

Thanks for the information but it did not help in solving the problem still...

[Sundar_7]

If you are suspecting the application then let us try from the command line

1) make sure you have the above entries for local0.notice

2) Issue the following command

# logger -p local0.notice "Hey this is a test"

# cat /var/opt/SIU_01/log/sysloglocal.log

Do you see anything in there ?- do you see atleast an empty file getting created automatically ? - did u send the HUP signal to syslogd ?

- Sundar

[Saurabh Kapoor_2]

Hi,
When I send the message usinbg logger then it shows up in the /var/opt/SIU_01/log/sysloglocal.log

[Sundar_7]

OK now you have it confirmed that syslogd is properly configured to redirect the facility. The problem is with the application only. Would be a good idea to double-check the log facility name and level it uses.

[Bill Hassell]

logger is definitely the first tool to test logging. Note that syslog.conf is processed one line at a time, so if you don't want local# entries in certain logs, you'll need to use the NONE priority.

Another nifty feature is the -v option which will show you exactly what the program used to signal syslog (facility and level). Change syslogd to add -v in /etc/inetd.conf, then signal inetd to re-read the file with inetd -c. Now, there will be a codenumber that tells the facility and level. I've attached a script which will read a syslog file and decode these numbers into readable values. Note that it scans the entire log looking for a -v code. If not enabled, syslogdecoder reports that -v logging was not found. For a long syslog, this will take a while. It's a good idea to start a new syslog file if you change syslogd options.