Great, looking forward to it. Speaking of "<script>", since the patch is not yet applied, I'd sneak in a feat. req.: I've always though that it would be helpful to also have the route name (/number) in the log messages generated from script; now, I add it manually, but I guess that adding it automatically shouldn't be that difficult.
Bogdan. Ondrej Martinek wrote: > there's an example of the "stderr" log output: > $ ser -ddDDEf test.cfg > > ============== > SER compiled w/ -DNO_DEBUG: > > Listening on > udp: localhost [127.0.0.1]:5070 > 0(18127) BUG: <core>: get_sock_info_list: invalid proto 4 > Aliases: > > 0(18127) WARNING: <core>: tcp_options: tcp_connect_wait depends on > tcp_buf_write, disabling... > 0(18127) INFO: <core>: init_tcp: using epoll_lt as the io watch > method (auto detected) > 0(18127) BUG: <core>: core limits increased only to 4194304 > 0(18127) WARNING: xlog: xl_mod_init: DIFFERENT hostname 'ds2' and > gethostbyname 'ds2.sip-server.net' > 0(18127) INFO: <core>: udp_init: SO_RCVBUF is initially 110592 > 0(18127) INFO: <core>: udp_init: SO_RCVBUF is finally 262142 > 4(18131) INFO: <core>: signal 2 received > 2(18129) INFO: <core>: signal 2 received > 3(18130) INFO: <core>: signal 2 received > 3(18130) INFO: <core>: signal 15 received > 0(18127) NOTICE: <core>: Thank you for flying ser > > ============== > SER compiled w/o -DNO_DEBUG: > > Listening on > udp: localhost [127.0.0.1]:5070 > 0(21524) BUG: <core> [socket_info.c:201]: get_sock_info_list: invalid > proto 4 > Aliases: > > 0(21524) WARNING: <core> [tcp_options.c:102]: tcp_options: > tcp_connect_wait depends on tcp_buf_write, disabling... > 0(21524) INFO: <core> [tcp_main.c:3744]: init_tcp: using epoll_lt as > the io watch method (auto detected) > 0(21524) BUG: <core> [daemonize.c:344]: core limits increased only to > 4194304 > 0(21524) WARNING: xlog [xl_lib.c:1691]: xl_mod_init: DIFFERENT > hostname 'ds2' and gethostbyname 'ds2.sip-server.net' > 0(21524) INFO: <core> [udp_server.c:166]: udp_init: SO_RCVBUF is > initially 110592 > 0(21524) INFO: <core> [udp_server.c:217]: udp_init: SO_RCVBUF is > finally 262142 > 2(21526) BUG: <script>: Slow timer executed > 3(21527) BUG: <script>: Fast timer executed > 2(21526) BUG: <script>: Slow timer executed > 3(21527) INFO: <core> [main.c:729]: signal 2 received > 3(21527) INFO: <core> [main.c:729]: signal 15 received > 1(21525) INFO: <core> [main.c:729]: signal 15 received > 5(21529) INFO: <core> [main.c:729]: signal 15 received > 0(21524) NOTICE: <core> [main.c:640]: Thank you for flying ser > > ============== > > Ondrej Martinek wrote: >> Hi guys, >> >> I've already made some changes to the logging in SER. The log >> messages will automatically include the severity, the position >> (filename and line) and the module name (or "<core>"/"<script>" >> string). Currently, it's being reviewed by Jan Janak. >> >> Moreover, I wrote a script that replaces LOG(static_severity, ...) by >> corresponding dedicated macros and removes the module name and the >> severity string from the log messages in SER sources. >> >> Regards >> --ondra >> >> Bogdan Pintea wrote: >>> I was actually wondering: shouldn't all logging be, finally, leveled? >>> >>> Right now, there are 3 logging types: >>> - using dedicated macros for severity (ERR, WARN etc); >>> - LOG(<severity>, ...), manually beautified -- severity and maybe >>> function name present (the case of current commit); >>> - as previous, but either no severity or no location info, or both >>> missing; >>> >>> This is "hard" to deal with, both for a human and an automated log >>> parser (besides the unprofessional, chaotic looks :-) ) . >>> >>> Are there clear disadvantages against sticking to only logging with >>> dedicated severity macros and (progressively) migrate all log >>> statements to that model? >>> >>> >>> Bogdan. >>> >>> PS. I know not all compilers in all their versions have location >>> helpers and that manual beautifying helps with those, but this >>> support should nowadays be marginally (if at all) needed; besides, >>> current status is mixed enough to be uncomfortable in those >>> situations, as well. >>> >>> Nils Ohlmeier wrote: >>>> calrissian 2008/08/24 00:15:43 CEST >>>> >>>> SER CVS Repository >>>> >>>> Modified files: >>>> . forward.c Log: >>>> fixed wrong function name in error message >>>> Revision Changes Path >>>> 1.118 +2 -2 sip_router/forward.c >>>> http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/forward.c.diff?r1=1.117&r2=1.118 >>>> >>>> >>>> _______________________________________________ >>>> Serdev mailing list >>>> [email protected] >>>> http://lists.iptel.org/mailman/listinfo/serdev >>>> >>>> >>> >> _______________________________________________ >> Serdev mailing list >> [email protected] >> http://lists.iptel.org/mailman/listinfo/serdev -- Bogdan Pintea iptego GmbH http://www.iptego.com _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
