crashinfo doesn't support compressed crashdumps - which way forward?

Larry Rosenman ler at lerctr.org
Thu Jul 12 14:51:53 UTC 2018


On Thu, Jul 12, 2018 at 08:50:08AM -0600, Alan Somers wrote:
> On Thu, Jul 12, 2018 at 8:31 AM, Mark Johnston <markj at freebsd.org> wrote:
> 
> > On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote:
> > > Hi,
> > >
> > > the crashinfo script doesn't know how to handle compressed coredumps.
> > > What would be acceptable behavior (ordered by my preferrence)?
> > >   1) decompress in /var/crash and then proceed normally (already
> > > implemented locally)
> > >   2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished
> > >   3) keep it like it is
> > >   4) teach tools to understand compressed dumps (gzip / zstd)
> >
> 
> I briefly looked into this option, but it's harder than it sounds.  There
> are several libraries that would need to be modified, and I think some of
> them work by mmap(2)ping the core file rather than by fread(2)ing it.  I
> don't know of anyway to mmap a compressed file.
> 
> 
> > >
> > > Implicitly there is the question what what is the purpose of
> > > compressing crashdumps, to have more RAM than space in dumpdev (which
> > > is valid in my case), or to save space in /var/crash (which I don't
> > > care much about).
> >
> 
> Compressed crashdumps are also great for systems with slow dumpdevs.  They
> greatly speed up the dumping process.
> 
> 
> >
> > I think jhb has a patch which implements 2).  I do not have strong
> > feelings on which is the right way forward, but I mildly prefer 2) to
> > 1).  It looks like crashinfo can be disabled in rc.conf, so users who
> > are space-constrained in /var/crash can take the additional step of
> > setting crashinfo_enable=NO.  FWIW, when I committed the compression
> > support, my use-case involved both a small dump device and a small
> > /var filesystem.

I have jhb's patch applied and it works great.

borg.lerctr.org /usr/src $ svn diff
Index: usr.sbin/crashinfo/crashinfo.sh
===================================================================
--- usr.sbin/crashinfo/crashinfo.sh	(revision 336184)
+++ usr.sbin/crashinfo/crashinfo.sh	(working copy)
@@ -38,6 +38,13 @@
 	exit 1
 }

+# Remove an uncompressed copy of a dump
+cleanup()
+{
+
+	[ -e $VMCORE ] && rm -f $VMCORE
+}
+
 # Find a gdb binary to use and save the value in GDB.
 find_gdb()
 {
@@ -133,7 +140,7 @@

 	# Figure out the crash directory and number from the vmcore name.
 	CRASHDIR=`dirname $1`
-	DUMPNR=$(expr $(basename $1) : 'vmcore\.\([0-9]*\)$')
+	DUMPNR=$(expr $(basename $1) : 'vmcore\.\([0-9]*\)')
 	if [ -z "$DUMPNR" ]; then
 		echo "Unable to determine dump number from vmcore file $1."
 		exit 1
@@ -174,8 +181,16 @@
 fi

 if [ ! -e $VMCORE ]; then
-	echo "$VMCORE not found"
-	exit 1
+    	if [ -e $VMCORE.gz ]; then
+		trap cleanup EXIT HUP INT QUIT TERM
+		gzcat $VMCORE.gz > $VMCORE
+	elif [ -e $VMCORE.zst ]; then
+		trap cleanup EXIT HUP INT QUIT TERM
+		zstdcat $VMCORE.zst > $VMCORE
+	else
+		echo "$VMCORE not found"
+		exit 1
+	fi
 fi

 if [ ! -e $INFO ]; then
borg.lerctr.org /usr/src $
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler at lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 679 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20180712/17205202/attachment.sig>


More information about the freebsd-hackers mailing list