RE: [syslog-ng]syslog-ng mysteriously exits
Are you referring to the SIGHUP bugs(s)? -----Original Message----- From: Ed Ravin [mailto:eravin@panix.com] Sent: Friday, February 08, 2002 12:40 PM To: syslog-ng@lists.balabit.hu Subject: Re: [syslog-ng]syslog-ng mysteriously exits John Coke writes:
getpid() = 3616 time(NULL) = 1013148201 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 getpid() = 3616 kill(3616, SIGABRT) = 0 --- SIGABRT (Aborted) ---
I have not been able to find a clear picture of what causes SIGABRT.
This is self-inflicted - note that the process looks up its own process ID number (getpid()), diddles the signal mask (I'm guessing it's to enable SIGABRT), then kills itself. syslog-ng has probably detected something very wrong, and is trying to leave you a core dump so you can figure out what happened. So my next question is - where's the core dump? It should show up in the current directory of the daemon. Use "lsof" while the daemon is running to see what directory it is in, and check there. Or do a global find and hunt it down. Also, have you tried upgrading to the latest syslog-ng (1.5.14 or so)? Except for one small bug :-) it's worked pretty well for me. _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
John Coke writes:
Are you referring to the SIGHUP bugs(s)?
No. I'm referring to assert(3) or the moral equivalent. See the relevant man pages. Any luck in finding the core file? Also, check your ulimit settings, you might have core files disabled.
getpid() = 3616 time(NULL) = 1013148201 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 getpid() = 3616 kill(3616, SIGABRT) = 0 --- SIGABRT (Aborted) ---
I have not been able to find a clear picture of what causes SIGABRT.
This is self-inflicted - note that the process looks up its own process ID number (getpid()), diddles the signal mask (I'm guessing it's to enable SIGABRT), then kills itself. syslog-ng has probably detected something very wrong, and is trying to leave you a core dump so you can figure out what happened.
John Coke writes:
Are you referring to the SIGHUP bugs(s)?
Oh, please ignore the previous note I sent, I just realized you were posting at the top of that message about the little comment I'd made at the bottom:
Also, have you tried upgrading to the latest syslog-ng (1.5.14 or so)? Except for one small bug :-) it's worked pretty well for me.
Yes, I was refering in particular to the one where file sources are opened twice when SIGHUP arrives. My current workaround, I am sad to say, is to run both the original syslog and syslog-ng, and have syslog listen on /dev/klog, and forward the kernel messages to syslog-ng. Yuk.
participants (2)
-
Ed Ravin
-
John Coke