possible syslogd bug?
I have a dedicated syslog machine runnign 3.2 and vanilla syslogd (started with -vv flags). After running for a few day the file would grow (this time file was ~40MB) and syslogd would stop writing to a file and go into a weird state. Here is the ktrace of "hang" syslogd before I did 'reboot' dlog# kdump 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGTERM caught handler=0x804b178 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL sigprocmask(0x1,0x2001) 93 syslogd RET sigprocmask 16385/0x4001 93 syslogd CALL gettimeofday(0xefbfc08c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL writev(0x12,0xefbfc04c,0x7) 93 syslogd GIO fd 18 wrote 64 bytes "Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 " 93 syslogd RET writev 64/0x40 93 syslogd CALL writev(0x1d,0xefbfc04c,0x7) 93 syslogd GIO fd 29 wrote 64 bytes "Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 " 93 syslogd RET writev 64/0x40 93 syslogd CALL sigprocmask(0x3,0x4001) 93 syslogd RET sigprocmask 24577/0x6001 93 syslogd CALL unlink(0x804c9e5) 93 syslogd NAMI "/var/run/log" 93 syslogd RET unlink 0 93 syslogd CALL exit(0x1) System also shows syslogd is in poll() state when it hangs .. I did not see anything wrong with syslogd.c when I looked. The file is now at 62MB, I see if I can debug this further next time syslogd hangs. -- yan P.S. -- Yes, *.* is going into that file ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
possible syslogd bug?
I have a dedicated syslog machine runnign 3.2 and vanilla syslogd (started with -vv flags). After running for a few day the file would grow (this time file was ~40MB) and syslogd would stop writing to a file and go into a weird state. Here is the ktrace of hang syslogd before I did 'reboot' dlog# kdump 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGTERM caught handler=0x804b178 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL sigprocmask(0x1,0x2001) 93 syslogd RET sigprocmask 16385/0x4001 93 syslogd CALL gettimeofday(0xefbfc08c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL writev(0x12,0xefbfc04c,0x7) 93 syslogd GIO fd 18 wrote 64 bytes Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 93 syslogd RET writev 64/0x40 93 syslogd CALL writev(0x1d,0xefbfc04c,0x7) 93 syslogd GIO fd 29 wrote 64 bytes Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 93 syslogd RET writev 64/0x40 93 syslogd CALL sigprocmask(0x3,0x4001) 93 syslogd RET sigprocmask 24577/0x6001 93 syslogd CALL unlink(0x804c9e5) 93 syslogd NAMI /var/run/log 93 syslogd RET unlink 0 93 syslogd CALL exit(0x1) System also shows syslogd is in poll() state when it hangs .. I did not see anything wrong with syslogd.c when I looked. The file is now at 62MB, I see if I can debug this further next time syslogd hangs. -- yan P.S. -- Yes, *.* is going into that file ;) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Hey kernel hackers, this is worth a read.
On Fri, Jul 30, 1999 at 08:58:09PM -0700, "Jordan K. Hubbard" [EMAIL PROTECTED] wrote: http://features.linuxtoday.com/stories/8191.html A story on upcoming plans for the Linux 2.4 kernel. Since they're going after a lot of the same performance goals we are, it's worth a read. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From the article: "Linux 2.4 also includes a completely rewritten networking layer." Great. After a few years from now when they get all the bugs out, they will be right back to the quality of early 4.4BSD quality ;) However, the SMP stuff they are working on is something we need IMHO. -- yan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hey kernel hackers, this is worth a read.
On Fri, Jul 30, 1999 at 08:58:09PM -0700, Jordan K. Hubbard j...@zippy.cdrom.com wrote: http://features.linuxtoday.com/stories/8191.html A story on upcoming plans for the Linux 2.4 kernel. Since they're going after a lot of the same performance goals we are, it's worth a read. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon [EMAIL PROTECTED] wrote: A sandbox is a security term. It can mean two things: [...] UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon dil...@apollo.backplane.com wrote: A sandbox is a security term. It can mean two things: [...] UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
