Hi, 2009/7/27 Yu Watanabe <yu.watanabe@jp.fujitsu.com>:
TO : Mr.Panel
Hello Vincent.
Thank you for the reply.
I understand that the non BSD-syslog date format log comes into syslog-ng , it does not operate properly.
This isn't entirely correct. syslog-ng supports several time formats, if you can read C code then take a look at the log_msg_parse() function in src/logmsg.c. When it comes to syslog-ng 3 then the parser is a little bit more complex.
Could I ask you three questions about this syslog message? It would be a great help if you could afford time answering with these questions.
1. I would like to confirm my thought about this. More specifically, I saw the packet using tshark. And, in the "Message:" area, the properly handled packet always has the process id in its beginning.
Like , "128: Jun 09 2009 16:30:19: %SYS-5-CONFIG_I: Configured from console by console" And , no matter what kind of date format was included in the message it was properly parsed in syslog-ng.
syslog messages should start with *priority* enclosed between '<' and '>'. Please show the complete/ unedited packet dump for a proper analysis.
I thought the reason why it was not parsed correcly, was whether the process id had existed or not in the packet. Am I on the wrong point? I apologize if I was giving a wrong opinion.
I tend to disagree. I don't see any PID in the above line but as it should come *after* the program name the presence of PID doesn't really matter.
2. Just want to confirm if syslog-ng stops processing the destination driver process, whenever it goes messy with the PROGRAM macro?
No.
3. So for now , to escape from syslog-ng being inproper, should I not use the PROGRAM macro?
If the log isn't parseable then PROGRAM could be either blank or contains inproper data - so the obvious answer is to don't use macros which depend on the successful parsing of the message in this case. hth, Sandor