Subject: Re: Problem with gcore and permissions
To: Christos Zoulas <firstname.lastname@example.org>
From: D'Arcy J.M. Cain <darcy@NetBSD.org>
Date: 01/11/2005 17:30:44
On Tue, 11 Jan 2005 16:31:36 -0500
email@example.com (Christos Zoulas) wrote:
> On Jan 11, 3:02pm, darcy@NetBSD.org ("D'Arcy J.M. Cain") wrote:
> -- Subject: Re: Problem with gcore and permissions
> | On Tue, 11 Jan 2005 14:45:12 -0500
> | firstname.lastname@example.org (Christos Zoulas) wrote:
> | > The third reason is that the process cannot write to the directory
> | > or file where the core is supposed to be generated. You can use
> | > sysctl to change proc.<pid>.corename to something else, or update
> | > to head and use gcore -c <corename> <pid>. Finally a better way is
> | > to ktrace or attach gdb to it.
> | I'm running this as root so I assume that directory permissions are
> | not the issue.
> If "this" refers to gcore, being root matters as far as getting
> permission to trace the process to tell it to generate the core. If
> the process being traced (in this case PostgreSQL) does not have the
> right permissions to write the core file, then you'll get an error.
> The core file is written using the PostgreSQL credentials.
I assume that it drops it into the current directory. The process does
have permissions there. Perhaps I need to make sure that the process is
started in the pgsql directory.
Nope. I just tried to gcore the sshd, named, mountd and a few other
root processes and none of them worked either.
> | Funny you should mention attaching gdb as that is the other
> | thing that fails. If I try to attach it tells me something about
> | already debugging and then kills the PostgreSQL process when I exit
> | gdb.
> That is probably because there is another ktrace or gdb attached to
> it. Does ps show 'X' in the status column?
Nope. I have rebooted (and rebuilt) many times and I am the only person
working on this system. Also, ps does not show 'X' in the status
> | Note that gcore fails on -current as well. The gdb attach works
> | fine though. Unfortunately, so does PostgreSQL (it doesn't get into
> | a busy loop) so I can't use that to track down my PostgreSQL
> | problem.
> So the problem is fixed :-)
In -current, yes. But we can't leave our release in that state, can we?
That's why I am trying to debug this with the 2.0 branch instead of the
release. I am hoping we can fix this for 2.0.1 or at least 2.1.
D'Arcy J.M. Cain <darcy@NetBSD.org>