Summary: | ASTERISK-10432: [patch] Logging goes to wrong destination | ||
Reporter: | non-poster (non-poster) | Labels: | |
Date Opened: | 2007-10-02 14:18:22 | Date Closed: | 2011-06-07 14:08:05 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 20071002__issue10871.diff.txt | |
Description: | Some log messages show up in /var/log/messages on my machine. Code: # grep -v ^\; /etc/asterisk/logger.conf [general] [logfiles] syslog.local0 => notice,warning,error,verbose,debug /etc/syslog-ng/syslog-ng.conf: filter f_asterisk { program(asterisk); }; destination asterisk { file("/var/log/asterisk/messages"); }; log { source(src); filter(f_asterisk); destination(asterisk); }; destination messages { file("/var/log/messages"); }; filter f_messages { not facility(auth,authpriv,kern,mail,daemon) and ... not program(asterisk) and ... ; }; log { source(src); filter(f_messages); destination(messages); }; The messages: Oct 1 18:39:04 myhostname unparseable log message: "<--- Transmitting (NAT) to 192.168.49.99:55954 --- >" Oct 1 18:39:04 myhostname SIP/2.0 401 Unauthorized Oct 1 18:39:04 myhostname Via: SIP/2.0/UDP 192.168.49.99:55954;branch=z9hG4bK-d87543-71067059a5075507-1--d87543-;received=192.168.49.99;rport=55954 Oct 1 18:39:04 myhostname From: "myhostname"<sip:6100@myhostname.com>;tag=407c2746 Oct 1 18:39:04 myhostname To: "myhostname"<sip:6100@myhostname.com>;tag=as7a8d5495 Oct 1 18:39:04 myhostname Call-ID: MzQ0ZmE5Nzg5MjI0ZWQxYjJkNGFiZjFhYzk1YWI0OGQ. CSeq: 3 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="myhostname.com", nonce="24e57166" Content-Length: 0 <------------> Oct 1 18:53:46 myhostname HTTP/1.1 404 Not Found Content-Type: text/html Content-Length: 345 Date: Tue, 02 Oct 2007 01:53:46 GMT Server: lighttpd/1.4.18 Oct 1 19:27:35 myhostname unparseable log message: "<--- Transmitting (NAT) to 192.168.48.100:5060 --- >" Oct 1 19:27:35 myhostname SIP/2.0 100 Trying Oct 1 19:27:35 myhostname Via: SIP/2.0/UDP myhostname.com;branch=z9hG4bKpqqzyktg;received=192.168.48.100;rport=5060 From: "non-poster" <sip:nonposter@myhostname.com>;tag=sgmhb To: <sip:18003733411@myhostname.com> Call-ID: totikozjpilfjfs@myhostname.com CSeq: 100 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:18003733411@192.168.48.1> Content-Length: 0 <------------> The "unparseable log message" comes from syslog-ng. Asterisk 1.4.11, gcc 4.1.2, glibc 2.5, amd64 | ||
Comments: | By: Jason Parker (jparker) 2007-10-02 14:35:08 I don't get it. You're telling asterisk to log everything to syslog. How is this an Asterisk problem? By: non-poster (non-poster) 2007-10-02 14:55:50 Yes, asterisk should (and does) send everything to syslog. However, my syslog rule should send everything that asterisk logs to /var/log/asterisk/messages, and most log entries do, except this one still goes to /var/log/messages, and syslog notes that it is unparseable. None of the other services on my system have ever caused syslog to log an "unparseable" message. By: Tilghman Lesher (tilghman) 2007-10-02 15:41:48 It relates entirely to Asterisk using the '<' character in the log message, which syslog-ng seems to think is a meta character. There isn't anything we really can do about this. It seems like a deficiency in syslog-ng itself, though none of the FAQs for that project even acknowledge that it's a problem. In any case, this works fine if you use the traditional syslog daemon, and I encourage you to make the transition. By: non-poster (non-poster) 2007-10-02 15:47:07 # grep \< /var/log/asterisk/messages|wc -l 1132 Other asterisk log entries contain "<", so apparently it is possible to use this character correctly in a message to be logged. Note that I will not be switching away from syslog-ng. By: Tilghman Lesher (tilghman) 2007-10-02 15:50:24 non-poster: if you can figure out what exactly syslog-ng does not like, I'm all ears. However, Google has a ton of examples of this error with no resolution. By: Tilghman Lesher (tilghman) 2007-10-02 18:10:41 Okay, figured out what syslog-ng doesn't like. It thinks that it should parse the initial '<', as if it were a numeric priority. So I've added a new option to logger.conf for the [general] section, which says "syslog_ng => true" if you want the alternate logging, which simply logs an '_' as the first character of the log message. That will stop syslog-ng from puking. By: non-poster (non-poster) 2007-10-02 18:16:47 Why add the complexity? Just change the bad log statements to have a space or '_' at the beginning. By: non-poster (non-poster) 2007-10-02 18:23:25 Example commands to find such log statements: find|xargs egrep -e ast_\(verbose\|debug\|log\).*\"\< find|xargs egrep -e ast_\(verbose\|debug\|log\).*\"\\\\n\< By: Tilghman Lesher (tilghman) 2007-10-02 18:46:43 It's not that simple. The messages arrive as a format and a list of arguments and by the time I know what the first character is, it's already too late to insert the '_'. So it's arguably better (and faster) to always insert the extra character when using syslog-ng. By: non-poster (non-poster) 2007-10-02 19:50:53 I don't understand. I thought code in Asterisk was the source of these bad log statements, eg the ast_log() or ast_verbose() or ast_debug() statements generate the message to be logged. I would expect that we could just change that code. Why isn't that simple? (I haven't done any development on this code, so I don't understand it's complexities, etc.) By: Tilghman Lesher (tilghman) 2007-10-03 17:58:38 I am not going to change the rest of Asterisk because of a bug in syslog-ng, especially as it is far from the only syslogger out there. The traditional syslog daemon works fine; this is a hack to get around the syslog-ng bug. By: non-poster (non-poster) 2007-10-03 18:54:08 The rest of Asterisk? A dozen (or less) log statements? Why "hack" the logging to accommodate this bug in syslog-ng? This is a poor way to work around (not even fix) the problem. Can I submit a patch to fix the logging statements to keep this "hack" from adding an unnecessary configuration option and the related code? By: Tilghman Lesher (tilghman) 2007-10-03 22:05:01 Quite right. Ask the syslog-ng project to fix the bug, please. By: non-poster (non-poster) 2007-10-10 21:46:50 It looks like version 2.0.5 of syslog-ng does not exhibit this problem. (Problem reported when using 1.6.11) |