summaryrefslogtreecommitdiffstats
path: root/etc
diff options
context:
space:
mode:
authorgavin <gavin@FreeBSD.org>2013-08-28 15:12:15 +0000
committergavin <gavin@FreeBSD.org>2013-08-28 15:12:15 +0000
commit3289affe76fc0e2203d4103c7e856aabd6f7aa32 (patch)
tree3d4c2ce1430dde15729a9efea86308277ac6e33f /etc
parent83cae05680206abe0b0cdb076aa4ff2e94fed7db (diff)
downloadFreeBSD-src-3289affe76fc0e2203d4103c7e856aabd6f7aa32.zip
FreeBSD-src-3289affe76fc0e2203d4103c7e856aabd6f7aa32.tar.gz
After writing a kernel core dump into /var/crash, call sync(8).
If we panic again shortly after boot (say, within 30 seconds), any core dump we wrote out may be lost on reboot. In this situation, we really want to keep that core file, as it may be the only way to have the issue resolved. Call sync(8) after writing out the core file and running crashinfo(8), in the hope that these will not be lost if we panic again. sync(8) is only called in the case where there is a core dump to be written out, so won't be called during normal boots. Discovered by: Trying to debug an IPSEC panic MFC after: 1 week
Diffstat (limited to 'etc')
-rwxr-xr-xetc/rc.d/savecore1
1 files changed, 1 insertions, 0 deletions
diff --git a/etc/rc.d/savecore b/etc/rc.d/savecore
index a39d5ba..2176be9 100755
--- a/etc/rc.d/savecore
+++ b/etc/rc.d/savecore
@@ -70,6 +70,7 @@ savecore_start()
if checkyesno crashinfo_enable; then
${crashinfo_program} -d ${dumpdir}
fi
+ sync
else
check_startmsgs && echo 'No core dumps found.'
fi
OpenPOWER on IntegriCloud