Summary:	ASTERISK-25872: logging to syslog despite my configuring not to
Reporter:	Brian J. Murrell (brian_j_murrell)	Labels:
Date Opened:	2016-03-29 14:24:26	Date Closed:	2016-04-17 09:01:30
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Core/Logging
Versions:	13.7.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 7.2	Attachments:
Description:	Even though I have (TTBOMK) configured Asterisk to do no logging to syslog: {noformat} [general] [logfiles] security => security console => notice,warning,error messages => notice,warning,error {noformat} I am still getting stuff logged to my {{/var/log/messages}} file: {noformat} 08:05:48 asterisk [Mar 29 08:05:48] #033[1;33mNOTICE#033[0m[8261]: #033[1;37mchan_sip.c#033[0m:#033[1;37m23945#033[0m #033[1;37mhandle_response_peerpoke#033[0m: Peer 'voipms-montreal3' is now Lagged. (108ms / 80ms) 08:05:58 asterisk [Mar 29 08:05:58] #033[1;33mNOTICE#033[0m[8261]: #033[1;37mchan_sip.c#033[0m:#033[1;37m23945#033[0m #033[1;37mhandle_response_peerpoke#033[0m: Peer 'voipms-montreal3' is now Reachable. (23ms / 80ms) 08:24:20 asterisk [Mar 29 08:24:20] #033[1;31mWARNING#033[0m[8268]: #033[1;37mchan_iax2.c#033[0m:#033[1;37m4986#033[0m #033[1;37mhandle_call_token#033[0m: Too much delay in IAX2 calltoken timestamp from address 168.215.88.98:47170 08:38:35 asterisk 08:38:35.783 icess0x7f5d71e  ICE session created, comp_cnt=2, role is Unknown agent 08:38:35 asterisk 08:38:35.784 icess0x7f5d71e  Candidate 0 added: comp_id=1, type=host, foundation=Ha4b16f7, addr=10.75.22.247:11246, base=10.75.22.247:11246, prio=0x7effffff (2130706431) 08:38:35 asterisk 08:38:35.784 icess0x7f5d71e  Candidate 1 added: comp_id=1, type=host, foundation=Ha4b1605, addr=10.75.22.5:11246, base=10.75.22.5:11246, prio=0x7effffff (2130706431) 08:38:35 asterisk 08:38:35.784 icess0x7f5d71e  Candidate 2 added: comp_id=1, type=host, foundation=Ha4b1608, addr=10.75.22.8:11246, base=10.75.22.8:11246, prio=0x7effffff (2130706431) 08:38:35 asterisk 08:38:35.784 icess0x7f5d71e  Destroying ICE session 0x7f5d71ee6d98 08:38:35 asterisk 08:38:35.784 stuse0x7f5d717  STUN session 0x7f5d70fa6298 destroy request, ref_cnt=4 08:38:35 asterisk 08:38:35.784 stuse0x7f5d712  STUN session 0x7f5d7198d9a8 destroy request, ref_cnt=3 08:38:35 asterisk 08:38:35.784  ice_session.c  ICE session 0x7f5d71ee6d98 destroyed 08:38:35 asterisk 08:38:35.784 stun_session.c  STUN session 0x7f5d70fa6298 destroyed 08:38:35 asterisk 08:38:35.784 stun_session.c  STUN session 0x7f5d7198d9a8 destroyed 08:38:35 asterisk 08:38:35.785 icess0x7f5d71e  ICE session created, comp_cnt=2, role is Unknown agent 08:38:35 asterisk 08:38:35.785 icess0x7f5d71e  Candidate 0 added: comp_id=1, type=host, foundation=Ha4b16f7, addr=10.75.22.247:10210, base=10.75.22.247:10210, prio=0x7effffff (2130706431) 08:38:35 asterisk 08:38:35.785 icess0x7f5d71e  Candidate 1 added: comp_id=1, type=host, foundation=Ha4b1605, addr=10.75.22.5:10210, base=10.75.22.5:10210, prio=0x7effffff (2130706431) 08:38:35 asterisk 08:38:35.785 icess0x7f5d71e  Candidate 2 added: comp_id=1, type=host, foundation=Ha4b1608, addr=10.75.22.8:10210, base=10.75.22.8:10210, prio=0x7effffff (2130706431) 08:38:35 asterisk 08:38:35.785 icess0x7f5d71e  Destroying ICE session 0x7f5d71ee6d98 08:38:35 asterisk 08:38:35.785 stuse0x7f5d712  STUN session 0x7f5d7198d9a8 destroy request, ref_cnt=4 08:38:35 asterisk 08:38:35.785 stuse0x7f5d717  STUN session 0x7f5d70fa6298 destroy request, ref_cnt=3 08:38:35 asterisk 08:38:35.785  ice_session.c  ICE session 0x7f5d71ee6d98 destroyed 08:38:35 asterisk 08:38:35.785 stun_session.c  STUN session 0x7f5d7198d9a8 destroyed 08:38:35 asterisk 08:38:35.785 stun_session.c  STUN session 0x7f5d70fa6298 destroyed 08:38:35 asterisk [Mar 29 08:38:35] #033[1;33mNOTICE#033[0m[8261][C-00026585]: #033[1;37mchan_sip.c#033[0m:#033[1;37m25697#033[0m #033[1;37mhandle_request_invite#033[0m: Call from '' (199.115.117.13:5070) to extension '9*011972592751158' rejected because extension not found in context 'inbound-anon-sip'. 08:39:07 asterisk [Mar 29 08:39:07] #033[1;31mWARNING#033[0m[8261]: #033[1;37mchan_sip.c#033[0m:#033[1;37m4022#033[0m #033[1;37mretrans_pkt#033[0m: Retransmission timeout reached on transmission ce4922779d8807cbff067d771d457838 for seqno 1 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions 08:39:07 asterisk Packet timed out after 31999ms with no response {noformat} and so on and so forth.
Comments:	By: Asterisk Team (asteriskteam) 2016-03-29 14:24:27.361-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Brian J. Murrell (brian_j_murrell) 2016-03-29 14:41:17.706-0500 Now that I think about it, I wonder if this is {{std\{out,err\}}} coming from Asterisk being funnelled back into syslog. Do the kinds of messages shown in the Description typically eminate from an Asterisk instance's {{std\{out,err\}}}? By: Joshua C. Colp (jcolp) 2016-03-29 14:46:06.984-0500 Yes, those are messages that can be output to stdout. By: Rusty Newton (rnewton) 2016-04-01 16:20:45.359-0500 I'm curious, what happens when you disable all logging in logger.conf? Do you still get any output to syslog? By: Asterisk Team (asteriskteam) 2016-04-16 12:00:01.766-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Brian J. Murrell (brian_j_murrell) 2016-04-17 09:01:30.670-0500 This indeed turned out to be the output from asterisks stdout/stderr being logged to the system log by the system.