The manual states that dumpdev "AUTO is the default as of FreeBSD 6.0" [1] However: # uname -a FreeBSD xxxxxx 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # grep dumpdev /etc/defaults/rc.conf dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). savecore_flags="" # Used if dumpdev is enabled above, and present. It looks like NO is still the default. Is there a reason why this should not be turned on even for production machines? I haven't read about any side effects, but it seems to be off by default for some reason. Please cc me on any responses since I'm not currently subscribed. Cheers Ari [1] http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
On Tue, Jan 17, 2012 at 06:37:34PM +1100, Aristedes Maniatis wrote:> The manual states that dumpdev "AUTO is the default as of FreeBSD 6.0" [1] > > However: > > # uname -a > FreeBSD xxxxxx 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > # grep dumpdev /etc/defaults/rc.conf > dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). > savecore_flags="" # Used if dumpdev is enabled above, and present. > > > It looks like NO is still the default. Is there a reason why this should not be turned on even for production machines? I haven't read about any side effects, but it seems to be off by default for some reason.The Handbook is incorrect, and I filed a PR for this matter last year (PR 159650): http://lists.freebsd.org/pipermail/freebsd-doc/2011-August/018654.html Worth reading: http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063541.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063542.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063543.html And the entire thread: http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063535.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
On Tue, 2012-01-17 at 18:37 +1100, Aristedes Maniatis wrote:> The manual states that dumpdev "AUTO is the default as of FreeBSD > 6.0" [1] > > However: > > # uname -a > FreeBSD xxxxxx 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 > UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 > > # grep dumpdev /etc/defaults/rc.conf > dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). > savecore_flags="" # Used if dumpdev is enabled above, and present. > > > It looks like NO is still the default. Is there a reason why this > should not be turned on even for production machines? I haven't read > about any side effects, but it seems to be off by default for some > reason. > > > Please cc me on any responses since I'm not currently subscribed. > > Cheers > AriIf you use bsdinstall(8) to install a machine from scratch it explicitly asks you about whether you want crash dumps enabled or not. As long as you're aware that the crash dumps are happening and know that you might need to clean up after them (remove stuff from /var, etc) there are no dangers. You just need to make sure wherever the crash dumps will wind up going (/var by default) has enough space to handle both the crash dumps and anything else the machines need to do. We currently have no provision for preventing crash dumps from filling up the target partition. I keep advocating for the conservative side of this issue, preferring that crash dumps be an opt-in setting until we have infrastructure in place to prevent them from filling the target partition. I still picture there being people out there who don't know what crash dumps are, wouldn't know they might need to clean up after them, and may be negatively impacted if the target partition wound up full without them knowing why. -- Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120117/3c3ecb18/attachment.pgp