Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759587AbXK1Mik (ORCPT ); Wed, 28 Nov 2007 07:38:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752306AbXK1Mic (ORCPT ); Wed, 28 Nov 2007 07:38:32 -0500 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:42558 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751586AbXK1Mib (ORCPT ); Wed, 28 Nov 2007 07:38:31 -0500 Date: Wed, 28 Nov 2007 06:38:23 -0600 From: Robin Holt To: Oleg Nesterov , Roland McGrath , Kawai@americas.sgi.com, Hidehiro , Davide Libenzi , Alan Cox Cc: Bron Nelson , Stephen Champion , linux-kernel@vger.kernel.org Subject: Can we make application core dumps interruptible? Message-ID: <20071128123823.GB919@lnx-holt.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1033 Lines: 22 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/