Using jails and djbdns
I'm running dnscache and tinydns on the parent system, started through daemontools with /usr/local/etc/rc.d/svscan.sh. I also have a number of jails configured in /etc/rc.conf My problem is the jails contain instances of Apache, qmail, and other DNS dependent services which need tinydns running on the parent system, but jails are executed before /usr/local/etc/rc.d/svscan.sh. So all the jails boot up first, then djbdns services are started. Is there some easy way to reverse this order, so svscan is started first and jails started afterward? Tony Arcieri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rcNG dependency ordering
After playing around with rcNG a bit more I think I have a better grasp of how to fix my djbdns and jails problem. However I was wondering why rcorder wasn't run on /usr/local/etc/rc.d/* in addition to /etc/rc.d/* in /etc/rc Tony Arcieri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Continued instability with 5.3-STABLE
I have a dual Opteron upon which seems to only stay up approximately two weeks at a time then spontaneously reboots. It's colocated so I can't ever see panic messages, and I don't have another system colocated at the same place I can use to gather debugging info. I've never managed to get the system to generate a crash dump either. It has a 1GB swap partition and 2GB of physical RAM but through the last few reboots I've been setting hw.physmem to 896M as the only custom parameter in loader.conf. The swap partition is labeled as follows: twed0s1b swap 1024MB SWAP And dumpdev is set in rc.conf as follows: dumpdev=/dev/twed0s1b /var/crash/minfree is set to 2048 Lately I built a kernel from GENERIC using the latest RELENG_5 sources and without SMP support and experienced a reboot after approximately 16 days uptime, roughly equivalent to how long it took the system to crash with SMP enabled. No core file was generated. The kernel was built using source checked out from RELENG_5 on February 18th. I'm not sure if any Opteron specific fixes have been applied to the branch since then. Are there any other means of gathering debugging data that would work in my situation? As is I'm still unsure if my problems are hardware or software related as I've still never seen a panic message from the system (hardware is a Tyan K8S motherboard in a Tyan Transport system) Should I look into using KTR ALQ to log KTR data to the swap partition, and if it fills up will it wrap over to the beginning? I've never used that feature before... Tony Arcieri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Logging panic messages
I'm running a 5.3 system with a kernel built from the latest RELENG_5 sources as of 15 days ago which has just experienced another sporadic reboot in a long sequence of sporadic reboots which have occured since the system was originally installed. It was up some 30 days without trouble before I colocated that, and after that it was up approximately another 30 days before it began exhibiting problems. Since then it has crashed approximately every 15-25 days or so. I originally configured a dumpdev only to discover that the size of swap must exceed physical memory by 1MB in order for it to work, which it does not, unfortunately. So dumpdev won't work to collect crash data. What I'm really in need of is some way to determine the cause of reboots, and panic messages aren't being logged. I've heard of patches to the kernel which would provide ways to do this such as network console support (my colo provider doesn't provide serial consoles). Does anyone have any suggestions as to how I could obtain a log of the kernel panics and any other pertainent information I would need to debug the problem? Are there any patches to write debugging data to the swap partition when the system panics in lieu of a complete kernel core, such as the panic message or even better, a KTR dump? As is I have absolutely no information to go on in debugging this problem. Tony Arcieri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Logging panic messages
On Fri, Feb 04, 2005 at 04:28:54PM -0500, Chuck Swiger wrote: You might set hw.physmem to a smaller value in loader.conf to fit within the amount of swapspace which is available: set hw.physmem=value MAXMEM (i386 only) Limits the amount of physical memory space available to the system to value bytes. value may have a k, M or G suffix to indicate kilobytes, megabytes and gigabytes respectively. Note that the current i386 architecture limits this value to 4GB. Thanks for the suggestion, I'll give that a try, and see if I can get it to generate a corefile the next time it crashes. last and dmesg don't give you anything, hmm? No, and neither do the logfiles, but I've read this is intentional to prevent the kernel from executing complex kernel code like the VFS after a crash to prevent deadlocking. That's unforunate, hmm, you might try leaving an ssh session logged in doing a tail -f on /var/log/messages and see whether you can get anything from that. All networking hangs whenever it crashes. I think my best bet is to try to generate a kernel core file now, but I was wondering if there had ever been consideration of using the dump infrastructure to record KTR dumps rather than an image of the kernel core. It seems like KTR would be a wonderful facility to debug the cause of an OS crash, but the current infrastructure makes it relatively impossible to use in a situation like mine. Tony Arcieri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
