From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13277 invoked by alias); 2 Sep 2011 14:35:56 -0000 Received: (qmail 13120 invoked by uid 22791); 2 Sep 2011 14:35:55 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,TW_XS X-Spam-Check-By: sourceware.org Received: from co300216-co-outbound.net.avaya.com (HELO co300216-co-outbound.net.avaya.com) (198.152.13.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Sep 2011 14:35:29 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPPoYE6HCzI1/2dsb2JhbABCqGV4gUYBAQEBAgESKEQLAgEIDQghEDIlAQEEARIIEweHUJtgApw5hgVgBJhZi3w Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Sep 2011 10:35:27 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Sep 2011 10:26:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 2 Sep 2011 10:35:25 -0400 From: "Worley, Dale R (Dale)" To: David Aldrich , "gdb@sourceware.org" Date: Fri, 02 Sep 2011 14:35:00 -0000 Subject: RE: Empty core dump file Message-ID: References: <41302A7145AC054FA7A96CFD03835A0A047BD8@EX10MBX02.EU.NEC.COM> <20110826131657.GW25065@radix50.net>,<41302A7145AC054FA7A96CFD03835A0A049A74@EX10MBX02.EU.NEC.COM> In-Reply-To: <41302A7145AC054FA7A96CFD03835A0A049A74@EX10MBX02.EU.NEC.COM> 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/msg00009.txt.bz2 > From: David Aldrich [David.Aldrich@EMEA.NEC.COM] >=20 > 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: >=20 > mount -t vboxsf -o rw,uid=3D1000,gid=3D1000 SVNProj /media/SVNProj >=20 > which I store in /etc/rc.local >=20 > If I omit uid the core file becomes empty. >=20 > The problem with this is that I must customise the mount command for > each user, i.e. mount needs their uid. >=20 > Is there a better solution for this problem please? 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. The ideal solution is to have the current directory be writable by the process, as that is by far the commonest situation in Un*x operations, and there are likely to be other standard system management operations that fail if the process cannot write its current directory. 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 into /media/SVNProj, change the permissions on that directory so they can. 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 the directory for the core file. So you could do echo '/tmp/core.%p' >/proc/sys/kernel/core_pattern and have all core files written into the /tmp directory. Dale