Brian A. Seklecki wrote:
So it turns out, since April, there have been two distinctive types of
crashes.
OK...
The unexplained SIGHUP, which we eventually tracked down to faulty
logging configurations (now using SYSLOG instead of file logging), and
an ongoing Sig11.
Ouch.
#0
Next step must be ktrace(8)/kdump(8) or GDB [1].
~BAS
So it turns out, since April, there have been two distinctive types of
crashes.
The unexplained SIGHUP, which we eventually tracked down to faulty
logging configurations (now using SYSLOG instead of file logging), and
an ongoing
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.
-
List
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].
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).
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
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
7 matches
Mail list logo
