On 4/6/2010 11:22 AM, Alan DeKok wrote:
I don't know. Try using a tool to watch the server memory over time. If it keeps growing... that would be an issue
After research, SIGKILL, SIGXFSZ, SIGXCPU are the only signals sent by the kernel -> userland on the part of setrlimit(2). FreeRADIUS differentiates different types of signals and does not respond to SIGXFSZ, SIGXCPU. I reckon these SIGTERMs are originating from within FreeRADIUS itself as it relates to signaling child threads, etc.: $ egrep -ir 'signal\(SIG' * main/radiusd.c: signal(SIGPIPE, SIG_IGN); main/radiusd.c: signal(SIGHUP, sig_hup); main/radiusd.c: signal(SIGTERM, sig_fatal); main/radiusd.c: signal(SIGINT, sig_fatal); main/radiusd.c: signal(SIGQUIT, sig_fatal); main/radiusd.c: signal(SIGTERM, SIG_IGN); main/radiusd.c: reset_signal(SIGHUP, sig_hup); main/util.c: signal(signo, func); modules/rlm_smb/smblib.c: signal(SIGPIPE, SIG_IGN); /* Ignore these ... */ Like right here: static void sig_fatal(int sig) { switch(sig) { case SIGTERM: radius_signal_self(RADIUS_SIGNAL_SELF_TERM); ... I'm going to have to track down calls to radius_signal_self() ~BAS