Bug #1734
closed
savecore is not picking up dumpdev if the device is not also swap
0%
Description
When playing around with swap cache I encountered the following problem:
swap was activated on the SSD, dumpdev as set in rc.conf remained on the
"old" disk-based swap device.
When panicing the system with debug.panic a dump would be written to the
dumpdev (disk). When rebooting savecore never found this dump, but it could
be manually restored from the dumpdev with savecore /var/crash
/dev/serno/9SF12T4Y.s2b
Here are some bits from my system, that might be helpful:
/etc/fstab:
/dev/serno/CVGB004100GX040GGN.s1a none swap sw
0 0
#/dev/serno/9SF12T4Y.s2b none swap sw
0 0
/etc/rc.conf:
dumpdev="/dev/serno/9SF12T4Y.s2b"
- sysctl -a |grep dumpdev
kern.dumpdev:
Even if I redo the dumpon settings, it remains empty:
atom# dumpon -v off
dumpon: crash dumps disabled
atom# dumpon -v /dev/serno/9SF12T4Y.s2b
dumpon: crash dumps to /dev/serno/9SF12T4Y.s2b (22, 0x30031)
atom# sysctl -a | grep dumpdev
kern.dumpdev:
It is also not related to using serno (which thought might be too long or
sth):
atom# dumpon -v /dev/ad6s2b
dumpon: crash dumps to /dev/ad6s2b (22, 0x30031)
atom# sysctl -a | grep dumpdev
kern.dumpdev:
So, I think what is happening is as follows: On a panic the dumpdev is
correctly determined and the dump is written to /dev/serno/9SF12T4Y.s2b.
When rebooting, savecore is not able to determine the dumpdev because
kern.dumpdev is empty and consequently can't find the core.
If I enable /dev/serno/9SF12T4Y.s2b again as swap in fstab, even after the
panic->reboot (the unsaved core still resides on the dev) and then just
reboot (no panic/core) savecore will find the core and save it when the
machine comes up again, because savecore goes through all the swaps in
fstab. So it is not a problem of the core, the device or savecore itself, I
think. But savecore not "seeing" the dumpdev.
Jan
Updated by polachok about 14 years ago
What is strange, is that the sysctl kern.dumpdev is empty:
- sysctl -a |grep dumpdev
kern.dumpdev:
It isn't strange. kern.dumpdev is not of a string, it's CTLTYPE_OPAQUE (actually
udev_t), as you can see at kern/kern_shutdown.c around line 658.
I think you can set dumpdev in /boot/loader.conf to make savecore happy.
Updated by polachok about 14 years ago
I was wrong. savecore doesn't look on dumpdev at all.
We can do something like this, I guess:
diff --git a/etc/rc.d/savecore b/etc/rc.d/savecore
index bc62b77..f55aff1 100644
--- a/etc/rc.d/savecore
+++ b/etc/rc.d/savecore@ -58,7 +58,7 @ savecore_start()
{
if [ X$dumpdev != X ]; then
echo "Checking for core dump..."
- savecore ${savecore_flags} ${DUMPDIR}
+ savecore ${savecore_flags} ${DUMPDIR} ${dumpdev}
return ${RC_CONFIGURED}
fi
}
diff --git a/share/man/man5/rc.conf.5 b/share/man/man5/rc.conf.5
index c7128fb..4329fe5 100644
--- a/share/man/man5/rc.conf.5
++ b/share/man/man5/rc.conf.5@ -2315,7 +2315,9 @ to turn this behavior off.
Indicates the device (usually a swap partition) to which a crash dump
should be written in the event of a system crash.
The value of this variable is passed as the argument to
-.Xr dumpon 8 .
.Xr dumpon 8
and
.Xr savecore 8 .
To disable crash dumps, set this variable to
.Dq Li NO .
.It Va dumpdir
Updated by dillon about 14 years ago
:Alexander Polakov <polachok@gmail.com> added the comment:
:
:I was wrong. savecore doesn't look on dumpdev at all.
:
:We can do something like this, I guess:
:
:diff --git a/etc/rc.d/savecore b/etc/rc.d/savecore
:index bc62b77..f55aff1 100644
:--- a/etc/rc.d/savecore
:+++ b/etc/rc.d/savecore
:..
Committed! I've hit this one too.-Matt