From: David Aldrich <David.Aldrich@EMEA.NEC.COM>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: Empty core dump file
Date: Tue, 06 Sep 2011 10:47:00 -0000 [thread overview]
Message-ID: <41302A7145AC054FA7A96CFD03835A0A04E1D9@EX10MBX02.EU.NEC.COM> (raw)
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F5881@DC-US1MBEX4.global.avaya.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.
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=/tmp/corefiles/core.%e.%p.%t
On Centos 5.5, script /etc/cron.daily/tmpwatch calls tmpwatch to periodically purge /tmp. This is good as it will delete old core files but I can't work 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 the core files are just stored in /tmp that would not be a problem.
Has anyone configured a similar set up successfully?
David
next prev parent reply other threads:[~2011-09-06 10:47 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)
2011-09-06 10:47 ` David Aldrich [this message]
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=41302A7145AC054FA7A96CFD03835A0A04E1D9@EX10MBX02.EU.NEC.COM \
--to=david.aldrich@emea.nec.com \
--cc=dworley@avaya.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