"Exiting normally" on FreeBSD -- Synopsis?
All: Did anyone ever track this down? I'm assuming the consensus is that the kernel is SIGTERM'ing the process when it exceeds login_class(3) restrictions in login.conf(5) Obviously, other reports have eliminated the usual sources of signals as a cause. As for the root cause, are we talking about a memory leek introduced in a recent version or something less insidious, such as threading/process concurrency defaults that exceed defaults for non-root users? I'm still seeing documented behavior on freeradius-2.1.8 on FreeBSD/amd64 RELENG_8_0, but not RELENG_6_3. The only thing that I can see that has changed is the max open file limits 6.3: open files (-n) 11095 8: open files (-n) 3520 I guess maybe lsof(8) or fstat(8) to try to track down possibly a file descriptor problem? Ahhh, Monday. ~BAS
Brian A. Seklecki wrote:
Did anyone ever track this down? I'm assuming the consensus is that the kernel is SIGTERM'ing the process when it exceeds login_class(3) restrictions in login.conf(5)
Try the git 'v2.1.x' branch. There are a number of fixes there. Maybe one will help.
As for the root cause, are we talking about a memory leek introduced in a recent version or something less insidious, such as threading/process concurrency defaults that exceed defaults for non-root users?
I don't know. Try using a tool to watch the server memory over time. If it keeps growing... that would be an issue. Alan DeKok.
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
With that patch, we observed an un-expected exit (running foreground in a detatched screen) with no debugging output to syslog/stdout/stderr, but I confirm that patch is in place using strings(1). Next step must be ktrace(8)/kdump(8) or GDB [1]. ~BAS 1. Oh god, please make it stop.
Brian A. Seklecki wrote:
With that patch, we observed an un-expected exit (running foreground in a detatched screen) with no debugging output to syslog/stdout/stderr, but I confirm that patch is in place using strings(1).
Which patch?
Next step must be ktrace(8)/kdump(8) or GDB [1].
*something* causes it to exit. Find out what, and the fix should be simple. Alan DeKok.
participants (2)
-
Alan DeKok -
Brian A. Seklecki