From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: David Aldrich <David.Aldrich@EMEA.NEC.COM>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: Empty core dump file
Date: Fri, 02 Sep 2011 14:35:00 -0000 [thread overview]
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222B1F5881@DC-US1MBEX4.global.avaya.com> (raw)
In-Reply-To: <41302A7145AC054FA7A96CFD03835A0A049A74@EX10MBX02.EU.NEC.COM>
> From: David Aldrich [David.Aldrich@EMEA.NEC.COM]
>
> 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=1000,gid=1000 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?
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
next prev parent reply other threads:[~2011-09-02 14:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 12:36 David Aldrich
2011-08-26 13:17 ` Baurzhan Ismagulov
2011-08-26 13:47 ` David Aldrich
2011-09-02 12:46 ` David Aldrich
2011-09-02 14:35 ` Worley, Dale R (Dale) [this message]
2011-09-06 10:47 ` David Aldrich
2011-09-06 11:14 ` Jan Kratochvil
2011-09-06 15:40 ` David Aldrich
2011-09-03 8:47 ` Baurzhan Ismagulov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD5674C3CD99574EBA7432465FC13C1B222B1F5881@DC-US1MBEX4.global.avaya.com \
--to=dworley@avaya.com \
--cc=David.Aldrich@EMEA.NEC.COM \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox