From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11895 invoked by alias); 6 Sep 2011 10:47:35 -0000 Received: (qmail 11883 invoked by uid 22791); 6 Sep 2011 10:47:34 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,TW_XS X-Spam-Check-By: sourceware.org Received: from cluster-a.mailcontrol.com (HELO cluster-a.mailcontrol.com) (85.115.52.190) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Sep 2011 10:47:16 +0000 Received: from rly09a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly09a.srv.mailcontrol.com (MailControl) with ESMTP id p86AiwnP000451 for ; Tue, 6 Sep 2011 11:47:12 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly09a.srv.mailcontrol.com (MailControl) id p86AhsGJ026116 for ; Tue, 6 Sep 2011 11:43:54 +0100 Received: from mail1.neceur.com (mail1.neceur.com [195.47.207.3]) by rly09a-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id p86AhrKX026055; Tue, 06 Sep 2011 11:43:54 +0100 (BST) Received: from intmail2.copc.neceur.com (intmail2.copc.neceur.com [172.29.177.11]) by mail1.neceur.com (8.13.8/8.13.8) with ESMTP id p86AhrQi005523; Tue, 6 Sep 2011 11:43:53 +0100 Received: from av1.neceur.com (av1.neceur.com [172.29.14.21]) by intmail2.copc.neceur.com (8.13.8/8.13.8) with ESMTP id p86AhqBk004674; Tue, 6 Sep 2011 11:43:52 +0100 Received: from av1.neceur.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 367F7296B83; Tue, 6 Sep 2011 11:43:52 +0100 (BST) Received: from EX10CAS01.EU.NEC.COM (unknown [172.29.155.132]) by av1.neceur.com (Postfix) with ESMTP id 28910296B7A; Tue, 6 Sep 2011 11:43:52 +0100 (BST) Received: from EX10MBX02.EU.NEC.COM ([169.254.2.163]) by EX10CAS01.EU.NEC.COM ([172.29.155.132]) with mapi id 14.01.0289.001; Tue, 6 Sep 2011 11:43:52 +0100 From: David Aldrich To: "Worley, Dale R (Dale)" , "gdb@sourceware.org" Subject: RE: Empty core dump file Date: Tue, 06 Sep 2011 10:47:00 -0000 Message-ID: <41302A7145AC054FA7A96CFD03835A0A04E1D9@EX10MBX02.EU.NEC.COM> References: <41302A7145AC054FA7A96CFD03835A0A047BD8@EX10MBX02.EU.NEC.COM> <20110826131657.GW25065@radix50.net>,<41302A7145AC054FA7A96CFD03835A0A049A74@EX10MBX02.EU.NEC.COM> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00020.txt.bz2 > > This is a file permissions problem because if I mount the shared > > folder with a specific uid the core file is correctly saved. So I > > must use a mount command such as: > > > > mount -t vboxsf -o rw,uid=3D1000,gid=3D1000 SVNProj /media/SVNProj > > > > which I store in /etc/rc.local > > > > If I omit uid the core file becomes empty. > > > > The problem with this is that I must customise the mount command for > > each user, i.e. mount needs their uid. > > > > Is there a better solution for this problem please? >=20 > As you say, this is a file permission problem. By default, the core file= is writtin > in the current directory of the process that has crashed; if the crashing > process cannot write into its current directory, a core file cannot be > generated. >=20 > The ideal solution is to have the current directory be writable by the pr= ocess, > as that is by far the commonest situation in Un*x operations, and there a= re > likely to be other standard system management operations that fail if the > process cannot write its current directory. >=20 > Can you arrange your processes to not change their current directory to > /media/SVNProj? Or if you really intend every user to be able to write i= nto > /media/SVNProj, change the permissions on that directory so they can. >=20 > Another approach would be to have the core files written in another > directory. I'm not sure of the details but the manual page core(5) says = that > with 2.6 kernels and 2.4 kernels after 2.4.21, there is a > /proc/sys/kernel/core_pattern file that seems to allow specification of t= he > directory for the core file. So you could do >=20 > echo '/tmp/core.%p' >/proc/sys/kernel/core_pattern >=20 > and have all core files written into the /tmp directory. Thanks for your suggestion of storing the core files in /tmp. I think that= will be very suitable for us. I have set the core pattern to: kernel.core_pattern=3D/tmp/corefiles/core.%e.%p.%t On Centos 5.5, script /etc/cron.daily/tmpwatch calls tmpwatch to periodical= ly purge /tmp. This is good as it will delete old core files but I can't w= ork out whether it will delete directory /tmp/corefiles. If it does, then = new core files will not be saved. Of course, with your suggestion where th= e core files are just stored in /tmp that would not be a problem. Has anyone configured a similar set up successfully? David