linux-kernel - Can we make application core dumps interruptible?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Nov 2007 06:38:23 -0600
From:	Robin Holt <holt@....com>
To:	Oleg Nesterov <oleg@...sign.ru>,
	Roland McGrath <roland@...hat.com>, Kawai@...ricas.sgi.com,
	Hidehiro <hidehiro.kawai.ez@...achi.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Bron Nelson <bron@....com>, Stephen Champion <schamp@....com>,
	linux-kernel@...r.kernel.org
Subject: Can we make application core dumps interruptible?

We have a customer machine with 4096 cpus.  When some user applications
crash, it begins dumping core and can tie up the filesystem and
processors for a considerable period of time.  Often, they contact the
user and the user says the core dump files will not be useful and they
reboot the machine.  They have already reduced the default core dump size
to not dump anything and taken all reasonable steps to limiting core dumps
while still allowing them to be useful for those users that need them.
They would like to not need to reboot.

They hoped for a couple changes, one of which is a way for a SIGTERM,
SIGKILL, or something along that line interrupting the core dump process.
Is this the correct direction to take?  Are there any better ideas for
handling this?

Thanks,
Robin Holt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/