20 Nov
2009
20 Nov
'09
1:14 p.m.
Hi all,
I have a problem with the DSYSLOG_ASYNC option in the Makefile.defs
If I have set this option I could not longer receive log messages in the
"normal" running mode (forking, debug level=2 stderr = no).
If I set the debug to 9 I receive logging messages, then via
$kamctl debug 2
is everything fine.
If the debug is set to 2 and I run the proxy in foreground I also
receive log messages.
Any way, I have tried to find out what is going wrong here and found
something in :
daemonize.c
At the end of the daemonize function is a for loop
int daemonize(int * own_pgid)
.
.
/* close any open file descriptors
32 is the maximum number of inherited open file descriptors */
for (r=3; r < 32; r++){
close(r);
}
.
.
The variable "r" is used for the return value of fprintf (Upon
successful return, these functions return the number of characters
printed ..).
At the moment I have no idea why this triggering this error and only for
the DSYSLOG_ASYNC option.
Furthermore why or for what is this for-loop good ?
Maybe I am totally wrong or off the track but I really want this async
logging.
best regards
Torben
20 Nov
20 Nov
6:35 p.m.
Hi all,
OK sorry, the variable "r" is re-set in the for-loop, my fault(better
think before write ;-) ).
But the loop is the problem in my opinion.
If I put a LM_* log direct in fron of the close(line208 in daemonize.c),
everything seems fine.
Which means the close command fails (maybe at the right fd).
regards Torben
Am Freitag, den 20.11.2009, 12:14 +0100 schrieb Torben Friese:
Hi all,
I have a problem with the DSYSLOG_ASYNC option in the Makefile.defs
If I have set this option I could not longer receive log messages in the
"normal" running mode (forking, debug level=2 stderr = no).
If I set the debug to 9 I receive logging messages, then via
$kamctl debug 2
is everything fine.
If the debug is set to 2 and I run the proxy in foreground I also
receive log messages.
Any way, I have tried to find out what is going wrong here and found
something in :
daemonize.c
At the end of the daemonize function is a for loop
int daemonize(int * own_pgid)
.
.
/* close any open file descriptors
32 is the maximum number of inherited open file descriptors */
for (r=3; r < 32; r++){
close(r);
}
.
.
The variable "r" is used for the return value of fprintf (Upon
successful return, these functions return the number of characters
printed ..).
At the moment I have no idea why this triggering this error and only for
the DSYSLOG_ASYNC option.
Furthermore why or for what is this for-loop good ?
Maybe I am totally wrong or off the track but I really want this async
logging.
best regards
Torben
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
26 Nov
26 Nov
1:40 p.m.
On Freitag, 20. November 2009, Torben Friese wrote:
OK sorry, the variable "r" is re-set in the
for-loop, my fault(better
think before write ;-) ).
But the loop is the problem in my opinion.
If I put a LM_* log direct in fron of the close(line208 in daemonize.c),
everything seems fine.
Which means the close command fails (maybe at the right fd).
Hi Torben,
did not dig in the code in question so far, but is this still the same problem
you reported on the user list, that it work on etch but not on lenny?
Regards,
Henning
4:55 p.m.
Hi Henning,
I have found out that this NOT a lenny problem. It is general.
Have you seen the other post :
####
If I set the debug(in cfg) to 4 the proxy write logging messages, then
via
$kamctl debug 2
is everything fine(still logging).
If the debug is set to 2 and I run the proxy in foreground I also
receive log messages.
#####
Another interesting thing is if you bring in a log at line 205
(daemonize.c) it is working:
LM_ERR("what ever \n");
for (r=3; r < 32; r++){
close(r);
}
It seems that close() is not able to close the fd for the log (return
value from mksock in syslog_async.c).
But If I let the for-loop counter start at 4 it is still not working.
After that I tried to set up log_fd as global( int log_fd=-1) and
include the headers, to check the "r" against the log_fd before execute
close(). But the same result.
Also a correct close(closelog_async()) in deamonize do not work.
I am open for any ideas, maybe I have oversight something. Could you
reproduce this ?
best regards
Torben
Am Donnerstag, den 26.11.2009, 12:40 +0100 schrieb Henning Westerholt:
On Freitag, 20. November 2009, Torben Friese wrote:
OK sorry, the variable "r" is re-set in
the for-loop, my
fault(better
think before write ;-) ).
But the loop is the problem in my opinion.
If I put a LM_* log direct in fron of the close(line208 in
daemonize.c),
everything seems fine.
Which means the close command fails (maybe at the right fd).
Hi Torben,
did not dig in the code in question so far, but is this still the same
problem you reported on the user list, that it work on etch but not on
lenny?
Regards,
Henning
27 Nov
27 Nov
7:36 p.m.
On Donnerstag, 26. November 2009, Torben Friese wrote:
I have found out that this NOT a lenny problem. It is
general.
Hello Torben,
ok, understand.
Have you seen the other post :
####
If I set the debug(in cfg) to 4 the proxy write logging messages, then
via
$kamctl debug 2
is everything fine(still logging).
This sounds fine.
If the debug is set to 2 and I run the proxy in
foreground I also
receive log messages.
You don't expect to receive log messages here? Do you've set fork=no, or
log_stderr=no?
#####
Another interesting thing is if you bring in a log at line 205
(daemonize.c) it is working:
LM_ERR("what ever \n");
for (r=3; r < 32; r++){
close(r);
}
It seems that close() is not able to close the fd for the log (return
value from mksock in syslog_async.c).
But If I let the for-loop counter start at 4 it is still not working.
After that I tried to set up log_fd as global( int log_fd=-1) and
include the headers, to check the "r" against the log_fd before execute
close(). But the same result.
Also a correct close(closelog_async()) in deamonize do not work.
I am open for any ideas, maybe I have oversight something. Could you
reproduce this ?
I did not found time to setup a test scenario today, should be able to do so
on monday.
Regards,
Henning
1 Dec
1 Dec
2:55 a.m.
On Donnerstag, 26. November 2009, Torben Friese wrote:
[..]
Another interesting thing is if you bring in a log at line 205
(daemonize.c) it is working:
LM_ERR("what ever \n");
for (r=3; r < 32; r++){
close(r);
}
It seems that close() is not able to close the fd for the log (return
value from mksock in syslog_async.c).
But If I let the for-loop counter start at 4 it is still not working.
After that I tried to set up log_fd as global( int log_fd=-1) and
include the headers, to check the "r" against the log_fd before execute
close(). But the same result.
Also a correct close(closelog_async()) in deamonize do not work.
I am open for any ideas, maybe I have oversight something. Could you
reproduce this ?
Hello Torben,
i've just was able to reproduce this on 1.5 branch.
henning@ca:~/projects/openser/branches/1.5$ ./kamailio -V
version: kamailio 1.5.3-notls (i386/linux)
flags: STATISTICS, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP,
PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:5958M
@(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $
main.c compiled on 00:29:27 Dec 1 2009 with gcc 4.3.3
Here i get log file output, regardsless if i use log_stderror or not, but only
with debug=3.
Dec 1 00:33:47 [7985] INFO:core:init_tcp: using epoll_lt as the TCP io watch
method (auto detected)
Dec 1 00:33:47 [7987] ERROR:core:main: install asynchronous syslog handler..
Dec 1 00:33:47 [7987] NOTICE:core:main: version: kamailio 1.5.3-notls
(i386/linux)
The second log msg was added from me, to see if the correct function is
called.
This is on a kubuntu 9.04, with version 1.5-5ubuntu3 of sysklogd.
When i use debug=2 in the cfg, aparently it not works.. Interesting, i'll
investigate more.
Regards,
Henning
5470
days inactive
5481
days old
5 comments
2 participants
participants (2)
-
Henning Westerholt -
Torben Friese